The Difference between Outcome and Output in Product Development
To be successful in product development, we must minimize the number of product features while also delivering what the customer will like. In other words, product development success is governed by our ability to maximize the “outcome” rather than “output” of product development. When I say “outcome,” I mean what the customer really appreciates, which may have no correlation with the amount of features produced or “output.”
To clarify how outcome instead of output is the main measure for product success, Jeff Patton, in his video “Using Design Thinking to Stop Building Worthless Software,” said that maximizing throughput (output) has little correlation with delivering products the customer likes. He added that his main concern was figuring out the problem to solve, what to build, and how to have ownership over the outcome. Therefore, instead of focusing on the output, Patton argued that the focus should be on the outcome through a discovery mindset for learning and understanding.
Consequently, outcomes can bring a myriad of benefits to the customer and the developing organization after the product is released. For further reading, you should check out Patton’s piece in StickyMinds, titled “Design Thinking: 4 Steps to Better Software,” in which he explains the four steps of implementing design thinking.
Similarly, the Kano Model provides a different perspective of the notion of an outcome. Named after Japanese professor Dr. Noriaki Kano, this model classifies product features according to how satisfied the customer is with them. These features can delight the customer, heighten his satisfaction, or meet his basic needs. Delighting features are what Patton termed as “product outcomes.”
In the same line of thought, Michael Lieberman's article, titled “Adding value to CSM: the Kano Model,” discusses using Kano analysis as a tool to measure the features' importance to the customer and to the performance of the business.
In my view, both Kano and Patton are advocating that discovering a feature that a customer likes can create breakthrough results much higher than producing many basic features. For this reason, it’s more important for a product owner to figure out what features should not be built instead of what features he wants the team to build.
Moreover, the product discovery mindset to figure out what features we should build is up-scaled to the organization. Notably, Jim Collins has coined the term “hedgehog” as a discovery mindset for organizations to discover what they are best at. According to Collins, a hedgehog is what the organization can be best at, but it is yet to be discovered. To illustrate, Collins provides examples of organizations that gave up their core products, which were their very reason for existence, to focus on different products.
To sum up, implementing a discovery mindset is essential to discovering what the customer will appreciate most. To enable that, Patton’s suggests shifting the focus in measuring product success to measuring outcomes.
I’d like to hear your feedback on measuring the amount of work the product team produces every sprint, and how it relates to customer satisfaction.
