3 Product Anti-Patterns to Stop RIGHT NOW!
As product people we have a unique opportunity to enable and empower. Yet so often we hang onto our egos, get in the way and strangle creativity…
Why are these behaviours so bad and how can we stop?
1. Stop getting in the way
First, get out the way. This anti-pattern often stems from a lack of trust, or a fear of missing out (FOMO) which can lead individuals to both seemingly rational and irrational behaviour. At best it can result in a desire to be a part of any and all conversations or meetings. At worst it can result in micromanagement, mistrust and disempowerment.
Not only is this demotivating for our team members, but it also has a direct impact on product quality and its fitness for purpose.
The danger here is twofold: as team members become demotivated, quality drops and problems creep in, but more importantly, because team members aren’t being exposed to the users, choosers or real problems, there is a chance the real needs will not be met. Instead, an edited, interpreted, secondhand view of the problem will be addressed.
Therefore as product people, we ought to step back, relax and trust. Trust our teams and trust the process. If you’re not at the workshop, chill out — trust them to work according to the objectives embraced.
We also need to ensure our teams have appropriate objectives and expectations.
This means not only giving our teams the full picture, with access to users and choosers — but also the full picture of our expectations and rationale. It is highly likely we’ll have information others will not have. We’ll have experiences, reading and nuggets picked up from here and there informing our current judgement. Others will have the same.
Therefore we will do well to provide an environment where all these perspectives are welcome and safe. This means setting ‘guide rails’ or ‘boundaries’ for the matter in hand. Not only does this give contributors and collaborators an indicator of whether their input is relevant, it also helps focus team creativity, since it can be concentrated within the guide rails.
2. Stop solutionizing
Second, we need to stop starting with solutions. This is what Dan Olsen calls “solution pollution”, where we pollute the problem we are trying to solve with too much about the solution, before we’ve fully understood the problem space.
I’m not suggesting we step out of the solution altogether — it’s likely we’ll have valuable impact. However, we do need to fall in love with our problems.
This is our opportunity as product people to do what we are well placed to do. Since we uniquely sit between tech, business and the customers we have a fantastic opportunity to explore and develop the problem. Why would we waste that opportunity and instead do what we’ve already gathered others to do?! Why try to develop a solution when that’s what we are asking the delivery team to do?
Embrace a shared understanding
Therefore let us not squash their creativity, but feed it with context, constraints, observations, analysis, interviews, research, user feedback and more. Better still, let’s get out the way (see point 1) and invite our teams to embrace the problem as well! Let’s make it our objective to create a shared and embraced understanding of the problem space so that everyone has ample opportunity to bring their wisdom to the solution.
Ensure business value
Additionally, however we also need to be sure we are solving the right problem. And to do that we need to understand the problem — and the outcomes solving it expects to bring us. That could be earning value: additional revenue, cost saving or option value. It could be learning value. Alternatively it could also be simple marketing hype or exposure: burning value.
Can we look each team member in the eye and tell them we are confident this problem should be worked on and why we believe it will deliver the desired outcome?
A great way to do this is through objective driven development. Perhaps you’re already doing that via Objective and Key Result (OKR) tools or similar. Can we find a way to say to our team “Here is the objective….”, “these are the key metrics we want to hit” and “this is the problem space, these are the users — now let’s go!”
On that basis, we are able not only to get out the way, but also empower our teams to discover, explore and build something they are invested and believe in.
3. Stop thinking you’re right
Thirdly, we need to stop believing we are right. Or that others are wrong. Picture the scene: we’ve stepped out the way, our teams are busy beavering away on a solution — and yet we believe they are WRONG! What do we do? Step in and offer our highly paid opinion? Complain loudly and look forward to saying “I told you so” — or put aside our ego, and let the product process decide?
It has to be said this is often far easier said than done. However, this is where validated learning techniques, iterative development and meaningful measurement come into play! This is where the beauty of continuous discovery and (true) minimum viable products really shines.
This is also where we need to recognise the true extent of our foresight! It is not as far as we think.
Therefore it is helpful to shift the way we think about our solutions, and even our problems. In reality everything we discuss is a belief, or a hypothesis. And our possible solutions are experiments or bets.
Jeff Patton speaks helpfully about this saying: would we bet our lunch on the success of this solution, or our car? Or our house? Or our pension? Yet so often in our short-sighted belligerent as product people we send our people off on epic journeys creating solution we may never see a positive return on investment! If we’re not confident we’ll keep our lunch money, how confident is the business on the prospect of forking out thousands in developer costs?!
In fact even in a world of “safer” experiments (or smaller bets), where the primary objective has been to learn, rather than earn — it’s not a certainty we’ll always be right. Listening to a podcast recently (I can’t remember which or where), I understood that one company running experiments was wrong 60% of the time!
Perhaps on that basis we ought to assume we are always wrong and let the process guide us and our teams to hypothesise, experiment, validate and learn. Even with internal facing tools (such as CRM or sales order processing) this is worthwhile, since we are all human!
Otherwise very expensive bets! Or unwise investment opportunities — all our eggs in one basket at a time.
None of these are particularly helpful behaviours. But I believe the last is the worst. Let’s get out the way. Let’s stop solutionizing. But most of all, let’s grow some humility and stop believing we are right — not only may it save our businesses some cash, but it will democratise our teams and let the results speak.
Does this resonate with you? What have I missed? What do you appreciate? Let me know your feedback below — I look forward to hearing from you!
