Valuing solution excellence in product management
😅 — This is a pretty risky title, especially as it’s likely landing in front of an overwhelmingly (and rightly) problem-focused community. I’m willing to take that risk if it means a fruitful conversation about how product managers go about solving problems and ultimately create sustainable products that people love. Hear me out and know that this isn’t a plea to ditch results or the problem.
Landscapes as a Foil
In a previous article, we explored how product roadmaps are often ineffectively used as an artifact to communicate product vision and direction — sometimes product managers use what may be better described as a “delivery plan” to explain “where we are going” to internal teams leaving folks wanting more. Instead, product managers can use a product landscape to help teams better understand the trajectory of product development and ground themselves in a component-based framework for long term direction. In short, sometimes product managers use the wrong tools when attempting to drive consensus about a problem.
In a similar but wholly distinct way, product managers can fall into a similar trap as it relates to product results— in some cases product managers focus too much on the problem at the expense solutions. Yes, there’s a time and a place to put the problem aside and focus on solution management.
I’ve seen this play out many times now, and I’m convinced there’s value in building a robust solution toolset to help teams build great products over and against an overly narrow focused view on results. If we look at the root of the landscape problem, my original goal was to help internal teams participate in a shared vision, giving them common language and a shared visual to understand a potential solution.
Let’s focus on that last point — yes, a product landscape is indeed focused on a solution. In fact, we need more effective tools to help communicate solutions, especially when those solutions are well informed by a robust set of opportunities and key results. Going further, we need to create a culture that is focused on sharing solutions regularly to promote consistent and wholistic products.
The Problem is still King
As Teresa Torres expertly synthesizes in her article on Opportunity Solution Trees, while teams do indeed work to understand both the customer context that informs results and the solutions that intend to change them, teams do not always have a way of connect the dots. In other words, it’s easy to focus on building solutions without the larger “why” driving the change. This is definitely a problem, and tools like opportunity solution trees can help teams bridge that gap.
This problem is so pervasive that product management software itself has implemented tools to help end users connect deliverables to product vision — solutions like Aha! use goals and initiatives as “imperatives” to drive key results. Productboard uses drivers as a way to link ideas to broader outcomes.
Still further, other frameworks, like OKRs as developed at Intel and embraced by Google, intend to help people connect individual tasks to the objective they work to fulfill. In Gannon Hall’s words:
“[OKRs] enforce the practice of focusing on the problem at hand, rather than the potential solutions one might employ to address the problems.”
Connecting solutions to the objective they try to solve is a necessary and foundational practice in product management.
The key point here is that we cannot abandon the problem for the solution — the need for bigger picture thinking and transferring ultimate goals of the team cannot be skipped. Every thriving product must be informed by a context grounded in the problem space of its users and sustained by clear and objective target results. This is true even at the micro level — the product mindset — asking why is always required. If you miss this point, the rest will seem silly.
As I continue to navigate the space of product leadership, I’m convinced that we should not be trying to solve every problem with the same tools — or more specifically, using the landscape example, that we should not expect the answer to “where we are going” to be exclusively key results or objective focused. Results alone leave me wanting.
Why? When teams focus too narrowly on results, sometimes there can be unintended effects. There’s an inherent risk involved in spending too little time working through solution methodology and as a product manger mitigating risk is key.
Perhaps this does not resonate with you and your team is excellent at delivering products. If this is you and you’ve managed to connect tasks with the bigger picture, this is a good place to be. If you’re struggling, however, with delivering cohesive solutions despite compelling goals, this is for you.
I’ll use Teresa Torres’ opportunity solution tree visual as an aid in each of the following points. We’ll walk through the risks inherent in focusing too much on a problem and not enough on comprehensive solution management.
The Risk of Product Silos
More than ever, with the push to go fully digital, the way that development teams are working is changing. It may seems like there are a countless number tools that teams use to address each part of the research & development process —Figma, Slack, Google docs, Github, etc. The number of tools can at sometimes drive divides between the teams that use them — Jira is for managers… Figma for designers… and Visual Studio for developers.
Working in disparate tools can inherently create silos. A “silo,” in this case is inherently negative — if a person or team is working in a silo, he or she may be oblivious or disconnected from what’s going on around them. This often leads to obvious misses or misalignments. Oftentimes, we work to break down silos and encourage cross team collaboration so that we avoid independently functioning teams and processes that are not transparent or accessible by other members of the org. Working in silos encourages mistakes.
This concept of a breakdown in communication between departments is accessible and pervasive — it’s unintentional and can even be described as “organic”.
While silos are oftentimes found across teams, this concept of a silo is equally applicable within a product organization. In the same way that silos exist across departments, so too can silos exist at the product level within the same department. Perhaps this takes the form of silos based on opportunity, silos based on use case, silos based on the product component, or even silos as it relates to the leader. In whatever way that it exists, the effect of long standing silos is always the same —a reduction in customer satisfaction and a lack of cohesion in delivered solutions.
We may visualize an opportunity or leader based silo this way:
In the example above, while teams may be focused on the right problems, even running experiments to prove that proposed solutions will have the intended effect, solutions can become siloed and cut off from the rest of the working org. In other words, product managers working to promote solutions A, B, and C, may have no idea that solutions D, E, and F are also being proposed. Good product leaders limit this from happening.
In my career, I’ve sometimes learned the hard way — in one example we were working to build a data entry tool (solution) with the intended effect of reducing the time it takes system admins to onboard a new company (result). Little did we know that another team had already created a framework to handle bulk data imports but for a different opportunity — API based integrations. Had we known teams working on similar solution spaces, we may have changed our approach and therefore reduced system complexity.
When we do not pay enough attention to the solution space, we end up with a disjointed or incomprehensible product.
If we extract solutions from the opportunity solution matrix, we can envision how those solutions relate to one another, perhaps like this:
Said differently, solutions depend on one another, especially when you’re working to solve solutions in the enterprise space. We cannot think of solutions only as they relate to their overall objective — we must think of them as a working system, connected and inter-related within a web of other solutions.
When we stitch those solutions together in a way that’s visually transparent, teams are more likely to create self-evident and comprehensive product models. If we do not, we may end up missing key relationships and delivering an incomplete product experience.
The Risk of Duplicitousness
Another problem caused by focusing too intently on the problem space at the expense of solutions is the risk of redundancy. Focus on the solid yellow “Solution B” bubbles below:
When product teams work without intentionally working to expose overlap in solutions, they can end up with duplicates. While a “2 for 1” is inherently appealing, when teams experiment and develop solutions independently, we run the risk of building two different versions of the same solution and therefore get a “1 for 2” type solution.
A real world example — in a previous life, my organization attempted to provide tools to help manage labor laws as it relates to worker time entry. Labor laws are inherently complex and can have as many interpretations as there are lawyers. That said, my company had multiple products related to this space, each with their own unique elements.
During the product development process, we noticed that we were building a solution to solve for a state specific law twice… once in tool A and once in tool B. The kicker, however, was that is was the same technology and the same logic under the guise of a different product opportunity. We could have developed one singular solution to address two different problems just as easily. Instead, we ended up with two slightly different solutions for the same problem and the same type of user.
In contrast to failing to see related solutions as in the first example, this example exposes solutions that are inherently the same and provide no other intrinsic value. Yes, you can indeed get two different sets of code that solve exactly the same problem. It’s not as uncommon as it sounds. Working to intentionally expose the solution space is one way to reduce risk of this happening.
The Risk of User Experience
When teams sacrifice a culture of solution collaboration for broader goals, user experience suffers as well. Whether this takes the form of inconsistency across components, incongruous styles, or user journeys that lack repeatable patterns, cohesion in a product matters.
When solutions are built without a strong focus on creating a system that makes sense as a whole, it’s easier to let user experiences diverge. This is even more true when product teams are organized by the end user experience itself as opposed to a functional or strategic theme. Perhaps it could look like this, using our existing pattern:
The risk of a poor user experience isn’t unique to working through the solution space, but it is a sneaky contributor that I’ve seen work its way into established organizations with strong design management and solid best practices. This is often unintentionally led by product teams who are doing the good and hard work of speaking with customers and experimenting with solutions that meet their opportunity space.
If there’s any takeaway here, it’s that product cohesion does not start with UX, development, or even plain logic — it starts with product. A well run product team, whether it’s for a single product or a portfolio of products, must create space to work through solutions for the sake of solution integrity and congruity in and of itself. We cannot let solving a problem break the cohesive elements of a product unless there’s compelling evidence to do so. Don’t let solving opportunities come at the expense of a system that makes sense as a collection of working parts or systems.
It’s clear that there are problems created when product teams swing too far to either end of the solution-problem continuum. Successful teams can’t have one without the other.
That said, in some circumstances, I have seen results based methodology used incorrectly, resulting in a culture of results at the expense of the solution. This is clearly not a good thing. What can we do to help find a solid middle ground? What’s the right level of solution mangement as it relates to product management?
I am not talking about the discipline of “solution architecture” as more commonly referred to in relationship to professional services. I am talking about the disciple of creating a cohesive, shared vision for product direction and content as generated by product managers for the sake of product based decisions.
There are a couple things we can do here:
Practice Product Modeling
I’ve used the term “product model” a few times now and it’s intentional. In a previous article, I argued that the practice of creating a mental model as a product tool sets the best product managers apart from their colleagues.
Teresa Torres further set the stage for my thinking here by highlighting the connection between top human achievement and the art of mental modeling. Using Anders Ericson’s book Peak: Secrets from the New Science of Expertise as a foundation, she artfully exemplifies how product leaders can use mental models as a way to do better product discovery. She literally reveals this in an almost thought by thought way within the content of her article. 💰
I argue that is is absolutely true and should be applied more broadly to how product mangers think about their solutions over and above methodology for arriving at the right questions. Mental models should also be used to drive towards the right solutions.
Product landscapes do exactly this by focusing on the practice of solution transparency. Landscapes might fill the space between solutions, helping organizations visualize solution connections. You can see that here with the dotted purple line outlining the solution space, and the pink connector lines showing relationships:
One of my colleagues put it this way:
The only thing that has really ever worked for me to drive towards solutions with a group is multiple iterations of standing in front of a white board writing down something (anything!) and then asking if I’ve gotten it “right.”
I use it as a way to draw out what people really think/want. Asking people what they think/want is important — but reflecting it back is even better.
The landscape definitely falls into this category — people can look at it and say “no, that relationship doesn’t exist in the way you represented it” or “you are missing something important over here”
There are certainly other tools beyond landscapes that fill this space similarly. You can use whatever tools best suit you and your working style, however, here are a few other suggestions:
- Mind Maps
- Process diagrams
- Product use case scenario libraries
Whatever tools you use, it’s important to give product teams the tools to speak the same language and understand how their problem/solution spaces interact with one another.
Establish Solution Focused Rituals
Kate Hutchinson in her podcast This is Product management: Product Maturation is Product Management with Shawna Wolverton, EVP of Product at Zendesk, asks some great questions as it relates to how product teams should grow out of the start up stage and into the enterprise stage. Shawna gives some great advice:
“When you’re gong really really fast, you can end up having some drift. Maybe you have some duplicated effort because no one is looking up. Make sure that you’re giving yourself time to go be autonomous, go fast, do great stuff, but make sure there are also points, whether monthly, quarterly, whatever it is, to come back together and make sure that you’re working across teams to ensure the thing you’re building together continues to make sense as a whole.” (paraphrased)
Whatever your ritual may be, stop to consistently revisit the way that the product team is conceptualizing solutions or even the problem space as a whole. Solutions shift just as rapidly, if not more rapidly, than the problem spaces they are trying to address. Product folk need consistent and safe spaces to ask big questions about how products should work with one another, whether the work they are thinking through is redundant with other use cases, and whether proposed designs and approaches match the overall congruity of the product at large.
Here are a few ritual ideas:
- Demo Fridays (as Shawna later goes to point out)
- Weekly solution critiques with a wide product/team audience
- The Use Case Blitz — the practice of giving the development team a scenario and rapidly trying to stitch together the correct solution in an existing tool or prototype. This gets juices flowing, revealing inconsistencies in thought or application in ways that development practices on their own do not. Plus it can be super fun.
Don’t leave this to chance. Without consistent emphasis on solution collaboration, there’s no guarantee it will happen on its own, especially when product managers are already strapped for time and sapped by the rest of the org for answers.
Cross Functional Prototyping
The last suggestion here is to intentionally encourage prototyping, especially clickable prototypes generated from tools like Invision, Figma, and Sketch, to cross product boundaries. This means going beyond the direct solution a design intends to test or reveal. This can be hard, especially when you just want to get your design done, but the results are worth it.
In my current org, we have many large simultaneous solutions being generated. Those solutions are distinct form one another, but they are inherently related at multiple levels detail. One of the things that we did that was hugely helpful was to combine prototypes with designs from other proposed solutions to get a sense for how the new designs would work in context of the other. While the prototype was larger and took longer to create, we took away key insights from user testing that helped reveal better product direction.
Similarly, when prototypes are combined, it forces product managers to speak the same language and develop solutions that are in line with the other. It’s all too easy to make solutions look the same, but in practice develop two totally different solutions.
Great product organizations focus on solving problems, not specific solutions. At the same time, product leaders cannot neglect a culture of creating solutions that are cohesive, transparent, and commonly understood by its internal teams. We need some intentional rhythms to revisit solutions in and of themselves.
When organizations focus on building a strong process to manage solutions, this has a freeing effect on product managers, allowing them to focus on problems instead of managing the process that enables products to be built. Too often have I seen this process neglected in the guise of focusing on results, or if you’re like me, focusing on making a specific client successful.
Perhaps this is simply good management. Perhaps the process of building and managing solutions is merely part of good company culture. Perhaps it’s not a simple as it sounds — I believe that we must develop a practice of solution management as it relates to the product org so that teams can be enabled to go fast and solve problems in creative and insightful ways.
Problems matter — so too does the integrity of the solutions is spurs.
______
What other solutions management tools or practices have you used to create excellent products?