I’m reading around problems, experiments, and solutions

There's a lot of product management talk at the moment about defining the product roadmap in terms of problems, rather than features or solutions. I will write up my reading on roadmaps another day, but today I wanted to collate and synthesise some of my reading on approaching individual steps, opportunities, and problems along the roadmap.

I recently watched the Bill Constantino's presentation, "Toyota Kata Unified Field Theory", it's ten minutes long and well worth your time. In the presentation, Bill outlines a method for moving from a current state to a solution, referred to as a "Target Condition", which is located outside our current area of knowledge; examples of a Target Condition might be to crack a new market, or reach a new level of efficiency. The method moves towards the desired Target State by identifying a series of problems between the current state to the Target Condition, pushing out the edges of the area of knowledge as you go. Eventually you have navigated a series of solutions, routing through what was unknown territory, and you are able to achieve the Target Condition.

Mark Rosenthal, on whose blog I found this presentation, summarises the process of the Improvement Kata neatly, and provides a nice animated GIF of the process (read the article, and you'll find the animation towards the bottom):

The process becomes one of progressively solving problems, identifying the next, and expanding our understanding. Once there is sufficient understanding to anchor knowledge and take the next step, do so. Step and repeat.

– Mark Rosenthal, Bill Costantino: Toyota Kata "Unified Field Theory"

So the path to a solution is to navigate feelingly across a field of experiments and related problems. Teresa Torres has related angle on "feeling navigation" with her Opportunity Solution Tree. The Opportunity Solution Tree starts with a clear Desired Outcome, like the Target Condition of the Toyota Kata. Working backwards from the Outcome, you identify a number of Opportunities based on your customer knowledge anchored in your customer research and contact. (In a recent Pragmatic Live podcast, Teresa describes how she prefers the term Opportunity to Problem, as Opportunity allows for finding moments of delight with one customer and bringing that delight to a broader audience. Interestingly the Bill Constantino presentation also avoids the more negative term "Problem"… something for me to ponder.) For each Opportunity, the team then works up a number of potential Solutions… and for each Solution areas of uncertainty or unknown elements are de-risked with targeted Experiments.

Start by defining your desired outcome. What’s the most important metric your team can impact? You want to pick an outcome that will drive the most value for your business right now.

Then start to enumerate the opportunities that might drive that outcome. Remember to stay in the problem space. If you can, do some generative research to frame the opportunities in the same way your customers would.

Finally, try to connect each of your solutions to those opportunities. If you have some solutions that don’t connect, look for a missing opportunity or set the solution aside. It’s a distraction for now.

Teresa Torres, Why This Opportunity Solution Tree is Changing the Way Product Teams Work

The whole article is worth a read and provides useful illustrations of the approach. In the article Teresa further describes how visualising the wider view of a team's approach allows that team to spot when they are overly focussed (jumping to a single Solution quickly, without considering alternatives or running sufficient experiments to check their direction), or overly broad and unfocussed (getting overly enamoured of the "infinite funspace" of all the possible Solutions for all the Opportunities, running many many experiments and never delivering value).

As I'm reading and musing how to apply these ideas in my own practice, I'm wary of imposing process and of becoming overly bound to that process. In Jeff Bezos' 2016 letter to shareholders, he writes:

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us?

Jeff Bezos, 2016 Letter to Shareholders

Naturally, there are times when experimental method and process are largely unnecessary. In a recent episode of the Roadmunk podcast, Melissa Peri talks about the necessity of considering and experimenting to ensure that we are building the right solution, but acknowledges this is not always necessary:

For example, I like to use a checkout page. Checkout pages have been explored. People have experimented with them. There are pretty well-known best practices in the industry of how to create checkout pages. Maybe I take some of those best practices. I implement a checkout page, launch it, and start measuring to see my results.

Product to Product: Melissa Perri on how to think like a product manager

There's always going to be steps we need to take, elements we need to build, which are necessary prerequisites to providing value to our customer, but which are not able to really magnify or multiply the value provided. Foundational elements. For these, where they're well understood elements like a login page or checkout, it's fine to follow best practice.

Those key elements of our products, the elements which will allow us to provide value and delight to our customers, and propel us past our competition, these are where we need to consider our approach carefully to ensure we give ourselves the maximum chance of success.

Let me know in the comments if you have any thoughts or feedback on these subjects. I'm learning.

I’m reading about… Product Managers

At WordPress.com VIP we're looking into more formal Product Management, to help ensure that all our teams are aligned behind a consistent vision and a clear set of priorities. As such, I've been reading around about the Product Manager role to understand best practices from other organisations and from leaders in the field.

As one of the founding parents of modern software Product Management,  I found Marty Cagan a good place to start:

I want [Product Managers] to understand they need to worry about all aspects of the business, but I also believe strongly in the importance of humility for a product manager, and I need to make sure they’re not thinking the title gives them anything beyond a shot at earning the respect of their team.

– Marty Cagan, My Favorite PM Interview Question

Are you just administering the backlog, or are you actually tackling and solving difficult problems for your customers and your business?

Marty Cagan, Product Manager vs. Product Owner Revisited

There's a phrase which originated with Ben Horowitz's post Good Product Manager/Bad Product Manager, "the CEO of the product". It's a phrase I initially railed against in my reading, particularly in context of our Automattic culture which values independent, self-motivated, and extremely capable individuals. In my initial thinking I was leaning more towards a collaborative model, but the Marty Cagan posts above (and some key chats with others in my team) have turned me around, and now I see the value of the responsibility and strong links between the measure of the product manager and the success of the product.

Horowitz points out that his Good Product Manager/Bad Product Manager article was written many years ago, but even with that perspective it's worth a read:

Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. A good product manager is the CEO of the product. A good product manager takes full responsibility and measures themselves in terms of the success of the product.

Ben Horowitz, Good Product Manager/Bad Product Manager 

Rarely do any delivery functions report to the Product Manager, meaning Product Managers are dependent on others to deliver the product they are measured on. A fact which is emphasised in this line from one of Marty's quotes above: "I need to make sure [Product Managers are not] thinking the title gives them anything beyond a shot at earning the respect of their team". This tension is felt keenly in some of the articles I've read, in particular:

…you are not the CEO of anything…

This may seem like mere semantics but the distinction is important. Too many product managers I meet buy into this trope of CEO-of-the-product and believe their role is to act like an authoritarian CEO, often with disastrous results. These product managers tend to believe they have all the answers, that they produce the best solutions and designs, and that their teams should just do what they’re told. They’re mini-CEOs after all!

…Truly successful product leaders instead embrace their lack of authority and lead their teams and the wider company through communication, vision, and influence. They focus on collaborating across the company, bringing together the best people to move the product forward, and setting those teams free to execute on their product vision.

Martin Eriksson, Product Managers – You Are Not the CEO of Anything

Having re-read the Eriksson and the Cagan posts, both seem to me to be arguing for very similar positions: leadership without authority, and closely linking the success of the product to the measure of the Product Manager. The reference to CEO is a positive assignment of responsibility, not a licence to a command and control style of leadership.

More on Product Management as I find it; as my honoured colleague John Maeda says, "I'm learning".