7 Ways to Elevate Product Thinking
When the only tool you have is a hammer, every problem tends to look like a nail.
A persistent problem I keep seeing is that some long-standing practices tend to take the place of better ways of doing things. I wrote about the example of product thinking and project thinking here, which is one way this happens. But so many other areas of product development are prone to this same problem. Rather than understanding the underlying issues and determining the best way to address, we can often fall into old habits or familiar thinking. Many times it’s not even a bad way of doing things. But we (and our organizations) can do better.
So how can we get out of some of our bad habits? How can we take our thinking to the next level?
Elevating Our Product Thinking
Understanding Problems over Gathering Requirements
The term “requirement” makes me cringe a little bit, and I try to avoid using it whenever discussing problems to be solved. The connotation of it implies a rigidity that simply doesn’t work for modern product development. And the way it has been used for years leads too many people to think of it as an order that is taken by the product manager or product team and incorporated into the product. It’s a requirement after all.
Gathering requirements has been happening for a long time, which is why it is such an ingrained way of doing things. But I’d argue that if you’re only gathering requirements and then prioritizing them, you’re missing most of the opportunities to build a great product and experience.
A requirement in this sense is really an initial idea or guess at a solution. And usually our initial guesses are wrong (sorry, but it’s true). That’s part of the reason I love the jobs-to-be-done framework (and one of my favorite books on the subject is Competing Against Luck). If you simply stop at gathering requirements, you haven’t gotten down to the actual job to be done — to understand the underlying need and if there is a better way of meeting that need.
To get to this level of understanding, we have to go beyond “gathering requirements” to truly understand users. A great way of doing this involves journey mapping and story mapping. (More to come on story mapping later, but if you haven’t already read User Story Mapping, go get it now. Absolutely a game changer.) As an example, we were recently going through the experience for a subset of users of our product. One request they had was a button to export data to Excel. If we would have stopped at that level, we would have missed the real need. As we dove into that request (or “requirement”), we found that the export was an intermediary step. The ultimate goal was to get the data into Salesforce. So what they really needed was to get information into a different system, not an export to Excel. These are the kinds of things we find as we really understand our users rather than simply take requirements.
Outcomes over Output
It is very easy to get caught up in the output. Output is easier to commit to and easier to measure. Delivering a feature is easy to understand. We committed to a feature, we built it, and now it’s out there. Done.
But this kind of thinking the creates poor experiences or features that no one uses. Rather than simply building features, we need to focus on the goals we’re trying to achieve. Building a feature is only part of that. We have to ensure that the feature helps us reach the goal. If it is meant to get more users, did it achieve that? If not, what is our next step to achieve the goal?
This is a major focus of our roadmaps, and what we’re trying to achieve with a good strategic roadmap. I wrote about this at length here, so I won’t belabor the point. But the focus should be on outcomes rather than outputs.
Value over Estimates
Along the same lines as the above, it is easy to get into a vicious cycle of estimation, sizing, etc. This seems to be intended to give comfort to teams and managers that everything has been estimated and will only take X weeks to complete. But the cycle gets worse as initial estimates are missed, forcing everyone to participate in more meetings to determine why the guesses were wrong and how can we make better guesses in the future. This, of course, leads to missing more timelines, creating more meetings, and on and on and on.
Do we really want our teams to be experts on guessing (if that’s even a thing)? Or do we want them to be experts on delivering value? Because we tend to put a lot of emphasis on one over the other. I’ve even heard it said that the mark of a good team is being able to give really accurate guesses. I’d argue the mark of a good team is being able to quickly and frequently deliver value to users.
I’ve found that this type of focus on estimates and timelines can actually be a substitute for delivering actual value. In my experience, nothing has quieted the calls for estimates and projections like delivering actual results. It’s certainly no silver bullet, but can help us make significant progress. So if we could take back a little bit of the time we’re committing to estimating and projecting, and use that to start to deliver small increments of value to users and stakeholders, maybe we can get out of the vicious cycle and focus on what we’re all trying to ultimately achieve: delivering value.
Shared Understanding over Comprehensive Documentation
In his book User Story Mapping, Jeff Patton gives some incredibly useful advice when it comes to documentation, particularly around requirements and user stories. First off, “You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations.” The purpose of stories isn’t to have some sort of complete documentation of the requirements on what to build (see above), but they are the starting point for the conversation.
The goal is to get to a shared understanding. Again from Jeff, “Stories get their name from how they should be used, not what should be written.” Most of us are probably familiar with the format of a story: As a [user] I want [a thing] so that I can [accomplish something great]. But it’s not about the format. It’s about the conversation.
It’s still far too common to think of handoffs between groups as the way of doing things. Siloing people into buckets/areas of responsibility that don’t cross over. The stakeholders give requirements. The product manager documents them. The team builds it. But that is how terrible software gets made. What we need is more collaboration between groups. The product manager should facilitate the understanding. The development team should be involved early on with stakeholders and users. The right solution is a joint effort, not a series of orders or handoffs down the line.
This goes not only for the stories, but also for acceptance criteria. Too often we look at acceptance criteria as the final word on what should be built. But the same theme applies. If acceptance criteria are created before a shared understanding, they’re likely to be wrong. What we need is team collaboration on what is being built. And that’s not to say that good acceptance criteria for features aren’t important — they are — but rather that they shouldn’t take the place of ongoing conversations and shared understanding.
Just-in-Time Refinement over a Comprehensive Backlog
Another concept I’d challenge is the idea that a team should have months of refined stories ready to pull into sprints, so that the next few months are planned and ready to go. Again, not that I’m opposed to the principle of planning and refining. I’m actually in favor of both of those things. But do we really know exactly what we should be working on in a few months? If we plan out all the details today, do we expect there will be no changes in 3 months? No learning that will take place between now and then?
A better way is to get continually more granular as we get closer. We can certainly have a plan for the next few months and next few releases. Even to the feature level. We should be looking ahead and understanding upcoming needs and priorities. But shifting focus from our current priority to the planned priority 3 months from now, and trying to get the same level of detail for both, is the wrong focus. We can’t, and shouldn’t, think that we can fully prepare stories and development work, then let it sit for a few months, and simply pick it up and begin coding when its turn comes. Rather, our energy is much better spent on the specific details of the very near-term, the broader details of the short-term, and the strategy of everything beyond that.
High-Integrity Commitments over Comprehensive Project Plans
All too often we fall back into the trap of putting dates on every possible feature and commitment from now to the end of the year (or other time period). The idea of a comprehensive project plan that will guide all our work and hold the team accountable is fraught with problems.
In one of my favorite product management books Inspired, Marty Cagan talks about high-integrity commitments. The idea being that we shouldn’t be putting dates on every single thing we do. Rather, we should only be making commitments to dates when it is necessary for a very good business reason. And when we commit to dates, it’s not a wild guess, but a well-researched and understood date that both sides can agree on. And we do this only when it is crucial. That way commitments to dates are meaningful.
Again, we put the focus on the outcome we want to achieve, not the output. And we don’t drive our teams to exhaustion with endless dates. We make and keep meaningful commitments. And they are meaningful because they are not the norm.
Real-World Experience over Textbook Simplicity
Finally, every approach needs to be modified for the context it’s being used in. There is a ton of great advice out there, and many great examples of how to do things well. But almost everything will need to be modified and adjusted for the world you’re working in. It is one thing to understand the principles and methods. It is another thing to appropriately apply them to the user cases and business problems you’re solving.
That is part of what makes product development and product management such an exciting and difficult thing. It is as much art as it is science. There isn’t necessarily one “right” way of doing things, as much as we may want to think that.
It is a balancing act. On one side there may be folks who say things like “that will never work here.” On the other side, there are folks who say things like “all you need to do is XYZ. It’s easy, I’ve done it before.” Be wary of either mindset. While we want to continually push for best practices, some of them need to be modified to fit. But that certainly doesn’t mean it can’t work here.
At the end of the day, the goal is to improve the lives of the users of our products. But we often can get caught in mindsets that keep us from achieving that goal as effectively as we might otherwise be able to. Often we have to get out of our comfort zone, and help others get out of theirs as well, in order to do great things.
You can follow me on twitter here:
Subscribe to my new product newsletter here:
You can check out our product podcast here:
