The tradeoff between ‘Best’ and ‘Pragmatic’
The tradeoff between ‘Best’ and ‘Pragmatic’
Going from problem, to solution, to execution
So you’ve identified what the right ‘next’ problem is, how would you solve it? Don’t answer that! You’re surrounded by engineers, professional problem solvers. See how they would solve the problem. Teach them all that you’ve learned about this problem you’ve been obsessing over and let them brainstorm different possible solutions. Encourage them to diverge and converge, and they’ll eventually determine the best solution. The best product that they can build which will solve the right problem the right way.
Unfortunately it’s not that simple. Does the perfect product, the proposed solution make business sense? How much time do you have to solve it? Are you staffed to build the product well? Will this work with your legacy systems and existing tech debt? There are constraints that you might be under from your organisation and business which could render the best product, the best solution, infeasible. Ideally you build the best product possible, but you also need to be pragmatic. The ‘best’ solution is the wrong solution if there is no pragmatic way to build it.
As a Product Manager you must always be evaluating the tradeoff between ‘best’ and ‘pragmatic’, and that means there are pros and cons for every decision. Based on the constraints you are under, you may need to make concessions, cut corners, accept tech debt, or launch too early in order to maximise your impact. These are potential consequences of satisfying your constraints.
But what are the consequences of not satisfying those constraints? Answer that question too. A time constraint might have serious consequences if missed, like missing a Christmas launch for a retail product. But maybe the deadline is arbitrary. It could be something in between, like trying to minimise the ‘investment’ part of the ‘return on investment’ equation such that building the product makes business sense. Similarly, if the best product wouldn’t be compatible with your existing systems, that doesn’t necessarily mean it’s the wrong thing to build. It instead means that there is additional investment needed to adapt or redesign those systems before actually using the product widely. Not impossible, but a tradeoff to consider. These constraints are actually tradeoffs too.
Engineering should help you understand the consequences of choosing a suboptimal solution, and you should help engineering understand why those consequences are probably worth it for the impact you expect to achieve. Keep in mind that we’re building products under uncertainty, so there probably won’t be an obviously ‘correct’ answer. Even though we’re using data to make decisions we are still making assumptions for which tradeoffs will serve us best. And these assumptions can of course be wrong! Check your assumptions regularly and identify what you’ve got wrong as quickly as possible so you can evaluate changing course. This is crucial for the relationship and trust between product and engineering.
So accept that you need to make tradeoffs when building and shipping a product in order to maximise your impact. Start with the best possible solution and then evaluate the tradeoffs and concessions needed for pragmatism. Align product and engineering on the decisions, staying open to the possibility of being wrong. Build and ship a product. Solve a problem. Learn what worked and what didn’t. Do it again.
In our most recent Product Internals podcast, Arvid and I talk about determine what to build next such that the team is executing on our strategy. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!