Tyner Blain is a company focused on requirements management and software development processes. Scott Sehlhorst is the founder and president, with a background in both mechanical engineering and software (development, management, consulting).
View all posts by Scott Sehlhorst →
When solving complex problems at scale, we use epics, features, and stories to align, focus, and coordinate the work of multiple teams to achieve the objectives of our organizations.
An epic represents the investment decision to solve a tangible problem; a collection of epics together represent a broader investment decision to advance the organization’s strategy. Most of the teams I’ve worked with in the past few years initially think about their epics in the wrong way – and once we change together how they write problem statements, it unlocks their potential to achieve great things on their own.
In our continuing series on managing the risk in your backlog, we look at the risk of kidding ourselves. Specifically, we use cause and effect and hypotheses to identify the assumptions in our plans, but if we don’t do it the right way, we will lie to ourselves by validating our assumptions instead of responding to the truth when we see it.
When deciding how to invest in your product, you need to take into account the risks that your investments will not return the outcomes you desire. One class of risks is business risk, and in product management we can influence the business risk of invalid intentionality – what I could call “building the wrong thing.”
As Steven Haines first told me, “strategy first, roadmap second.” There is a step between the two – deciding which problems you will focus on solving with your product. Strategy defines the context for product strategy, and your product roadmap is a planning (and communication) tool for executing your product strategy. Understanding how problems are framed in your market is critical to developing a successful product strategy.
Understanding your users is critical to developing good products. A “complete” understanding is sometimes required, and always comes at a cost. A contextualized understanding is valuable but less so, and costly but less so. Even a shallow understanding of your users provides value by preventing some dysfunctional behaviors. You do not always need to develop personas before developing products.
You know you’re a product manager when this image causes more than a chuckle. A few random thoughts inspired by this Rorschach test of product management concepts from sunk cost fallacy to intentionality.
The pop-culture concept of a silver bullet – a simple solution to a hard problem – is a dangerous idea. It can be used to over-promise, and doom a team to under-delivery. When an executive, too far removed from what makes creating products hard thinks of “agile” as a silver bullet it becomes difficult to manage expectations.
Taking agile, a process otherwise optimized for small, cross-functional, collaborative teams and making it work at scale is fascinating. You have to change some elements, and retain others, as you redefine the context. Being outcome driven, is one element you must retain – or even elevate in importance, or you fundamentally break the system of delivery
Assumptions are interesting things – we all make them all the time, and we rarely acknowledge that we’re doing it. When it comes to developing a product strategy – or even making decisions about how best to create a product, one of these assumptions is likely to be what causes us to fail. We can, however, reduce the chance of that happening.
Being “outside-in”, “outcome-based”, and “market-driven” is particularly important for creating successful products. The problem is that just saying the words is not enough to help someone shift their thinking. For those of us who are already thinking this way, the phrases become touchstones or short-hand. For folks who are not there yet, these may sound like platitudes or empty words. I know many people who want to switch their roles from “do these things” to “solve these problems.” They have to change their organizations. This example may help get the point across.