Please Doc, Can I Have An Appendectomy?
Moving beyond product for its own sake and embracing a result-driven mindset
If you’ve ever seen the show House, you’ll know it’s about a genuis, crotchety doctor who goes around curing patients that no other doctor could help. In one episode, a boy mysteriously collapses playing basketball. House capitulates to the requests of the boy’s family to have an MRI with contrast, despite House’s being sure that this procedure will do nothing to progress the patient’s diagnosis. The team spends the rest of the episode dealing with a litany of life-threatening symptoms, ultimately attributed to complications from said MRI.
When I walk into a doctor’s office, I come in describing my symptoms, and I rely on my health care professional’s training and expertise to guide me towards a solution. Great doctors judge themselves on the outcomes that they achieve — whether or not I get better. The same principle applies to great product teams, they insist that they be judged not by anyone’s perceived quality of their product, but by the outcomes that their product achieves.
On outcomes
As a product manager, I believe it is my responsibility to help the engineers, designers, researchers, and other experts that I work with understand the impact of their work. That impact is not that they will have built something that someone figures will be important. Building something is not an achievement in and of itself, not as far as your users are concerned. Rather, solving a user’s problem is the achievement that product teams should seek.
Determining whether you’ve really solved a problem requires a definition of what it means to succeed. More sessions, more active users, reduced bounce rates. There are myriad ways to cut a path towards a measurable outcome for your product, and figuring out which one is right is easier said than done.
Ultimately, the outcome that you’re measuring is far more likely to come to pass than the one you’re not. I choose to believe that heading towards an imperfect, but well-defined outcome is better than making changes that I believe will achieve some far more fuzzy definition of success.
It takes extra work to work in this way. Establishing baselines, logging user activity, performing usership testing, and ultimately understanding where your idea stands in terms of the achieving of your solution is difficult and stressful. Difficult because a team that knows that their solution is perfect need not concern themselves with the work required to prove their solution’s perfections, and stressful because truly taking ownership of product in this way leads to teams who declare
here I am, judge me by my outcomes.
Fortunately, for me at least, there is no such thing as a solution that is perfect from the point of inception. If this were possible, than there would be little need for product professionals such as myself. Teams that understand that their solution is imperfect, and that it likely will always be imperfect, ask more questions. When these teams make potentially dangerous assumptions, they rush to prove them out. Where these teams encounter evidence that their current solution will not meet the agreed upon success criteria, they pivot quickly, since they know that they’re accountable for a solution’s success, or lack thereof.
On outcomes and teams
Teams are a key part of this equation. One of the benefits of setting your sights on an important outcome, and communicating that outcome and its importance, to a team is the freedom that it grants. Great product teams are full of experts who understand the problem that they’re trying to solve, enough to ask questions. Questions that lead to ideas and pivots and more questions and so on until all that remains are proven fixes. In this romantic world, I like to imagine a team rolling up its sleeves, putting their heads together, and teaming up in a glorious montage of user interviews and product iterations.
Building great product is extremely difficult, having a team of experts around is a great thing, but without being goal-driven, teams are just executing for executing’s sake. Great engineers want to know that they’re solving important problems, and there’s no faster way to alienate a product team than by asking them to blindly execute on a set of requirements, with no context as to the why that goes along with the what. Having your goal openly displayed in your team’s area, making measurement a part of your definition of done, and openly sharing metrics that tell your product’s story — good or bad — these practices can help your team stay centered on their overall goal. Talking to your team regularly, promoting a team culture of asking questions in the way you all talk about the product that you’re building, is my favorite way to affect this sort of change.
failures are just successes that haven’t happened yet
Part of the trouble with this sort of mindset is a natural aversion to failure. Failure gets a bad rap, and undeservedly so. Who would ever want to fail? Peter Theil, in an interview on the Tim Ferriss Show, highly recommended not failing if at all possible. Brilliant. How do we go about avoiding failure? One approach, embraced the world over by solution-driven teams, is to build the things that they’re asked to build.
In that world, building what you were asked to build is a very low-risk way to operate such that you’ll be viewed as being good at your job, but unfortunately it does not lead to the best outcomes for your users. These teams end up perpetrating the cardinal sin of product, as I see it. They weave stories of success. They paint rosy pictures about why their non-ideal outcomes are learning opportunities, about undiscovered features that solve a user’s problem. They’re doctors telling a gunshot victim that they successfully removed their appendix.
The other way to avoid failure is to embrace it. Teams that focus on outcomes are more open to the idea that any particular solution might not solve the problem. They understand the incompleteness of their notion of how a user might experience a problem, and they work to prove or disprove the assumptions that inform their idea of the best solution to said problem.
Failures and successes aren’t that different. The only real failure is a failure to acknowledge a solution’s flaws. Whether through a lack of effort in gathering information or through a bevy of politically charged reasons for not changing, failure is an important outcome.
By embracing failure to achieve an outcome as a possible, if not likely, outcome for any early project, teams spend more time working on successes. They quickly file away ideas built on faulty assumptions in the circular filing cabinet that we call the garbage can.
So let’s get out there, claim our outcomes, and tell the world that we will not be judged by any means other than the answer to “Have I affected a positive outcome for this company?”
How are you going to take ownership of your product’s success?
Thanks for reading! I’m Jack Moore. Feel free to give me a clap, or even a whole round of applause, it’ll help more people find my stuff.
