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
Continue reading Agile at Scale – Outcome Driven (or Broken)
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.
Defining and building a good minimum viable product is much harder than it sounds. Finding that “one thing” you can do, which people want, is really about a lot more than picking one thing. It is a combination of solving the minimum valuable problem and all of the other things that go with it. Solving for both the outside-in needs and the inside-out goals is critical.
How do you work with professional services, consulting, field engineers, etc. to make your product better? Do you just treat their inputs as yet another channel for feature requests, or do you engage them as an incredibly potent market-sensing capability?
Continue reading Professional Services and Improving Your Product
Product owners and product managers. Two roles, often done by one person. Together, the product people need to take an organization’s strategy, figure out the appropriate product strategy, and convert that into actionable work for the delivery teams to create the right product. What does the product manager own, and for what is the product owner responsible?