Product Over Process

While on a preschool tour for my toddler, I came across this poster describing “Product vs. Process.” It turns out “Product vs. Process” is a known early childhood educational framework. I’m a first-time parent, so I’m still learning. But seeing this got me thinking it could be a useful framework to apply to product management as well.

Broadly speaking, a product manager’s job is to identify the users’ problem, figure out the right solution, get that solution in the users’ hands, and iterate until it really solves the problem. Beyond that, PMs need to work with engineers to build that solution. Finally, they need to make sure it’s something users want to pay for (or that can be monetized in some other way).

Those last two parts of the job can sometimes lead PMs to obsess over the process at the expense of the outcome. Because these tasks are less focused on identifying solutions and more on building or prioritizing them, they can cause PMs to lose track of the problem they are solving.

I’ve seen teams be led astray by a misplaced focus on process over product in many ways. Here are three examples of typical process-focused pitfalls:

1. The “built to spec” trap
2. The pursuit of perfect product research, resulting in no research
3. Mindless application of prioritization frameworks

Let’s look at each of these in more detail.

The “Built to Spec” Trap

Sometimes PMs work to define the product specs in great detail, work with engineers to implement them, and then simply confirm that the product was “built to spec.” The problem with this approach is that the user doesn’t care if a product is built to spec. If the product doesn’t immediately do what the user needs, they will never use it.

Focusing on product over process during the execution stage means constantly evaluating whether the product does what it’s intended to do. This requires PMs to see the product through the users’ eyes and, more importantly, to figure out ways to do user testing even when it’s hard. It also means that the build process needs to be iterative. If you discover that the product doesn’t have the impact you’d expected, you should change it before it reaches the users — even if that means delaying launch.

Perfect Product Research Is the Enemy of Good

Speaking of user testing, it’s also prone to process obsession at the expense of product thinking. Folks sometimes wait for the perfect research opportunity that never manifests, causing the team to build a product no one needs. Don’t let perfect become the enemy of the good when it comes to user research and testing! When building a B2B product, take every opportunity to talk with customers, even if only to hear them react to a sales pitch.

For B2C products, there are simply no excuses. Talk with users. Follow them on social media. Read support questions, forum discussions, and app store reviews. Put your half-built product in the hands of people around you and watch them interact with it. A/B test what makes sense to A/B test. But don’t A/B test everything just because. A/B testing is also just a process. Sometimes it’s helpful. Sometimes it’s not, particularly if you don’t have enough data to reach statistical significance within a reasonable timeframe. Figure out what makes sense for your product.

Beware of Mindless Application of Prioritization Frameworks

Prioritization is another minefield for a process-focused PM. It’s easy to apply complex ROI analysis that obscures the features being evaluated and leads to building the wrong thing. This is more common in larger organizations where PMs need to defend their prioritization to lots of different stakeholders, some of whom only respond well to spreadsheets with numbers.

The problem with focusing on this process usually manifests when there’s no clear answer to engineers who later ask why they are building a feature. Another red flag appears when the sales team looks at the feature and doesn’t know how to sell it. Worst of all, of course, is when you ship the feature and users don’t engage with it at all. This can all be avoided by focusing on the problem that the product is trying to solve and constantly evaluating prioritization from that perspective. Don’t just rely on numbers spit out from a set formula.

This is not to say that all process is bad. Broadly speaking, it’s pretty much impossible for teams to collaborate without a process. The key is to make sure that process is always a means to an end — using the right process to fit the problem. That means tweaking existing product development processes when applicable or coming up with new ones that may work better for the specific situation. It also means throwing out a process if it ever gets in the way of building the right product.