Orienting to value – every team, every person does it differently. How you orient to value limits how much value you can create. People with a naive orientation can only scratch the surface, cogs in someone else’s machine; those with a refined orientation to value, well, there is no limit to what they can do.Continue reading Orienting to Value
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.Continue reading Epic Problem Statement
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.
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
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?
Product owners are likely to find themselves alone in the organizational wilderness. Their organizations expect them to connect the towers of long-term strategic planning with the frontiers of great new products. Iterative and incremental development of solutions can bring these two worlds together. There’s always a gap between strategy and execution – and product owners are ideally positioned to help fill that gap.
What we need is a survival guide – a set of principles, tools, and techniques; learned and applied in a two-day “camp” with industry-leading experts in agile product management and product ownership.
Last month, Mike Smart of Egress Solutions and I gave a webinar for Pragmatic Marketing on product roadmapping when working in agile environments. We had a great turnout of over 1500 people in the session – with not nearly enough time to answer all of the questions.
One attendee asked, “Please explain how a prioritized list of features is not a roadmap?”
A fantastic question, which we did not see in time to answer during the call.
We hear a lot about building products which are “good enough” or “just barely good enough.” How do we know what “good enough” means for our customers? No one really tells us.
Your product roadmap is a view of what you are building right now, in the near future, and in the more distant future. Or is your roadmap a view of why you are building whatever you’re building right now, in the near future, and in the more distant future?
Your roadmap is both – but one is more important than the other – and product managers need to be able to view the roadmap both ways.