February 23, 2025 -
I wrote this in 2019, during a time when I was trying to stop coding myself, and instead get things done by directing the efforts of other software engineers, as a Head of Product, then a product consultant. I was doing this for two reasons:
1) I was afraid that technical jobs would go away due to AI, and a general deprofesionalization of the software industry. To be clear, a lot of my past companies were trying to make this happen faster, so, while I feared this, I also kind of welcomed it.
2) I believed that I might actually enjoy PMing more than coding, because I could have more impact on a product.
After 2 years of this, I realized that, while my fear of coding jobs going away may be valid, it shouldn't play a part in my decision making today. I love software engineering, and I'm fortunate enough that I can be paid to do it. As long as that's the case, I'm going to write code.
I also realized that PMing means different things in different contexts, but most of them time, when I was paid to manage a product, it meant doing tasks that were closer to project managent. This kind of work is important, but I'm not very good at it, nor do I enjoy it. The kind of product exploration I enjoyed was easiest to do when I had my own projects— which meant I had to get back to coding myself.
“Flow” is the feeling you get when you’re totally immersed in a problem, receiving rapid feedback as you iterate on a solution. It comes up a lot with software engineers, who cite this state something they love about writing code.
When I was transitioning out of building software and into building companies I feared that my work would lack flow. Coding can rival video games in its ability to provide rapid feedback for hard problems. When I’m creating a web app with React there might be 10 seconds between having an idea and seeing it manifest in my browser.
Outside of coding though, feedback is slower. Nowadays, my ideas are expressed through emails, experiments and presentations— not code. If I’m not careful I’ll wait for hours or days to receive feedback. This kind of environment is not only boring, but also reduces the speed with which I can create a viable product. But, if I am careful, I can structure my work to generate more flow than coding. Here are the ways I do this:
I use my team as a proxy for real world feedback.
Real world feedback is always the ultimate judge of an idea, but it’s slow. Teammates exist to be speedier proxies for the real world! Whether I’m crafting an important email, or writing a pitch, I’ll always seek feedback from members of my team first.
Software Engineers have understood this for years. They use code reviews to make sure that they don’t wait for the real world to tell them if their code is maintainable or has bugs.
I try to set up similar structures for output review with my product team in addition to encouraging proactive brainstorming sessions and feedback over Slack, etc. If my team is frequently too busy to give feedback then I know it’s time to grow the team or reduce our scope.
I write about my ideas.
The best PMs I’ve worked with have all had journals where they develop ideas. When an idea is still too ill-defined to get feedback from my team, I’ll spend some time writing about it. Usually this writing is structured as a series of questions and answers— basically solo brainstorming,.
Before I wrote this post I had a doc where I generated and answered about 20 questions including “When do I experience flow at work?” and “How does that compare to the flow I get when writing code?”. This kind of writing allows me to experience flow and flesh out an idea before I get feedback from someone else.
I lower the barrier for real world feedback.
My goal is always to help my team get viable ideas in front of real stakeholders as quickly as possible. Again, this is both so my PMs enjoy their job AND so they make great products faster.
I do two big things to reduce time to market: 1) I make sure my PMs have good relationships with Sales and CX, so it’s easier to identify and contact potential testers. 2) I make sure the team celebrates any feedback we get from customers— positive or negative, so they continuously lower their bar for what qualifies as an MVP.
Do you experience flow as a PM? What have you done to create a feedback rich environment?