In life, it’s easy to find ourselves captivated by a single facet, to the point where we lose sight of the wider world. We become so passionate about these elements that our objective perspective often takes a back seat.

As a professional with a decade of experience, I’ve observed this narrative again and again. Rather than delving into the heart of the matter and navigating toward the optimal resolution, we habitually gravitate back to our customary practices or traditional modes of thought. More often than not, these aren’t inherently flawed tactics. However, it’s crucial to remember that both we, as individuals, and our organizations, harbor an untapped potential for growth and improvement.

So, what can we do to break free from some of these habits? How can we elevate our thinking?

Elevate Our Product Thinking

Unearthing Problems Instead of Just Collating Requirements

The word ‘requirement’ sounds so 1990s to me. It seems too rigid for the nature of modern product development. Too often, it’s seen as an absolute mandate, something that the product manager or team must integrate into the product, come what may.

However, this thought process, ingrained through years of practice, might be blinding us to bigger opportunities. If we only focus on collecting and prioritizing ‘requirements,’ we risk missing the chance to create a truly exceptional product and user experience.

Consider ‘requirements’ as initial ideas or tentative solutions. But let’s be honest, our first guesses are often off the mark. That’s why, the ‘jobs-to-be-done’ framework makes a lot of sense to me. If we only gather requirements, we haven’t dived deep enough. We’ve missed out on understanding the core need and exploring if there’s a better way to fulfill it.

To gain this level of comprehension, we need to transition from mere ‘requirement gathering’ to genuine user understanding. This often involves journey mapping and story mapping. For example, in my role as a product manager at Labra, we were analyzing the experience of a specific user group for our product. They requested an option to export data to Excel. If we had stopped there, we would’ve missed the actual need. Upon further investigation, we discovered that the Excel export was just a stop-gap measure. The ultimate goal was to understand the data and do an analysis. Their real need, therefore, was to analyze their data not just an Excel export. Discoveries like this are possible only when we strive to truly understand our users instead of just ticking off requirements.

Shifting from Output to Outcomes

It’s easy to become entangled in the web of output. Output, after all, is convenient to pledge to and measure. Delivering a feature? It’s a straightforward process. We promise a feature, we develop it, and voila, it’s live. Task completed.

However, this mindset can result in subpar experiences or unused features. Our focus should pivot from just churning out features to realizing the objectives they’re meant to achieve. Remember, building a feature is just one aspect. We need to ensure that this feature propels us towards our target. If the aim was to attract more users, did the feature accomplish that? If it didn’t, what’s our next move to reach the target?

This shift in focus forms the crux of our roadmaps and is the essence of a strategic roadmap. So, the takeaway message is clear: The spotlight should be on outcomes, not just outputs.

Emphasizing Collective Clarity Over Detailed Records

Documentations are not the remedy for improving requirements. Instead, they serve as a compass, guiding better discussions. The aim of documentation isn’t to produce exhaustive records of what needs to be constructed but to stimulate dialogue that leads to collective understanding.

We are aware of the conventional story structure: As a [user], I want [a thing] to achieve [an extraordinary outcome]. Yet, the real essence lies not in its format but in the discussions it fuels.

Regrettably, the handoff model where tasks are passed from one group to another remains a common practice. This model promotes siloed operations, with responsibilities neatly divided but hardly overlapping. Stakeholders provide requirements, the product manager documents them, and the team builds the product. Such an approach, however, breeds mediocre software. What we need is increased collaboration among groups. The role of a product manager should be to foster understanding. The development team should engage early with stakeholders and users. Crafting the right solution should be a concerted effort rather than a relay of commands and handoffs.

This shared understanding concept applies to acceptance criteria as well. Often, acceptance criteria are treated as the definitive guideline for what needs to be built. However, if these criteria are established before achieving a shared understanding, they are likely flawed. What we genuinely need is team collaboration on what’s being built. This isn’t to downplay the importance of well-defined acceptance criteria — they are crucial. However, they should never substitute ongoing dialogues and shared understanding to ensure we create engaging user-friendly products.

Valuing Practical Application Over Theoretical Simplicity

Lastly, the effectiveness of any strategy lies in its adaptability to the context in which it’s implemented. There’s an abundance of exceptional advice and stellar examples of efficient practices available. However, almost every piece of advice necessitates some form of modification to suit the real-world context of your work. Comprehending the principles and methods is one thing, but correctly applying them to your unique use cases and business challenges is another.

This is what renders product development and management both exhilarating and demanding. It’s a blend of art and science, with no exclusive ‘correct’ approach, no matter how much we yearn for one.

Product management is akin to walking a tightrope. On one side, you might encounter skeptics insisting, “That will never work here.” On the other side, you’ll find optimists declaring, “Just do it. It works, I’ve done it before.” Both these mindsets deserve caution. While we should consistently strive for best practices, it’s crucial to understand that these may need adjustments to fit your specific scenario. However, this does not necessarily imply that it can’t succeed in your context. Always keep in mind, adapting and learning from the real world is more valuable than adhering to textbook simplicity.

Ultimately, our mission is to enrich the user experience through our products. Yet, we can sometimes find ourselves trapped in habitual thought patterns that hinder our potential for progress. It’s imperative to dare to step beyond the comfort zone, inspiring others to do the same, to build meaning and valuable experience not only for the user but also for yourself.