3x3 ways to stop managing products and start discovering solutions
A product manager or a product owner? (I call it product managowners) Or perhaps a customer journey expert? Working with and in these roles, I believe differences between them are trivial and there is one emerging, underlying thread: we all are responsible for continuous solution discovery. And while there are still business cases where traditional product manager or product owner roles are required, increasingly this tradition is becoming obsolete.
What is continuous solution discovery
Instead of believing that we can manage our products, or spending days detailing and prioritizing user stories, we need to shift those pivotal roles towards continuous solution discovery.
It is not easy. But first, this is what it means:
CONTINUOUS— speeding up feedback loops so they basically merge into one continuous flow. PI events become non-events, sprint reviews become non-reviews, and new releases are business as usual. We ship any time and we use rolling forecasts instead of plans. Simply keep pushing for shorter cycle time.
SOLUTION— always focus on solving a real, existing, proven problem. First, we don’t design products and we don’t write code because we like it — we do it to perform a job. Second, a good solution is likely to combine elements of physical boxes, software, and services — and the boundaries are increasingly obsolete.
DISCOVERY— there is no simple or best way to create a solution. Instead, it requires to keep open mind, always. With everything you do, aim to generate new, more options — entertain them all but do not commit to a particular solution plan. Leave sufficient time for exploring and learning. Finally accept that there is no end-state.
3 enablers for continuous solution discovery
- Flexible technology— continuous integration and deployment is still a dream for many companies. Even if you cannot do CI/CD, prioritize work and design your systems to evolve, rather than towards a particular envisioned solution. Do not create perfect systems, but those that hold together for now and can change rapidly in the future.
- Customer feedback— always prototype and always quantify. Employ tools like customer journeys, service blueprints, or design sprints. Talk directly to customers. Don’t be ashamed to screw up — but have a fallback if that happens. Go for actual, hard, pain-inducing data that paints the real picture. Push everyone (I really mean everyone, also that man with a pinstripe suit) for customer feedback and actual data.
- Shared objectives — your customer facing and back-office roles working together towards the same shared objectives. No one in the organization has the job to burn story points or run excel reports. Everyone shares the goal to increase contract conversion rate or to reduce repair service cycle time — and some in the team contribute by streamlining a process, some by calling customers for feedback, and some with a nice piece of code.
3 organizational imperatives to transition into continuous solution discovery
- Set goals, not desired functionality — spend less time on defining what to create (i.e. writing features or user stories) and more on why we are creating something (i.e. setting out strategic solution direction and objectives). Focus on story — it is not about “as a … I want … so that” template to write specs but about a hypothesis that might, or not, turn out true. About half of your stories will fail the customer validation process and will never roll out. You know you are doing this well when no one with a title manager discusses features or user stories.
- Build solution teams — leave component teams to the past, leapfrog feature teams, and embrace solution teams. A team delivering results needs to be balanced between technical skills and business expertise (i.e sales, marketing, etc), cover a full technology stack, and have a full ownership of the problem space (customer contact, process design, case handling, etc, as well as codebase and APIs).
- Less rules, more judgement —significantly reduce a number of processes, job descriptions, standard templates and so on with the goal to increase the judgement space for people who are closest to the problem (see solution teams). Force tradeoffs as low in the organization as possible (see set goals). And leave it up to them to try, fail, learn, and succeed.
3 ways for a product managowner to get started today (pick your fav)
- Ask why — set one simple rule: before writing a line of code, have a verified customer need (through prototypes, concierge products, ethno research…). Product geniuses like Steve Jobs or Richard Branson are few and far between (even if many of us think we are)— and you’ll know when you work with one. So don’t accept opinions: if someone wants to have something built, better bring a proof of why it will contribute to the goal. This co-investment forces true collaboration. And if people ask why they need it, show them the hourly rate of a top-notch developer or designer.
- Measure one thing — define your lead KPI, set out the baseline, and track the progress frequently. This must be a business focused KPI — so no, story points completed do not count. Your simple attempt to set out a One Metric That Matters might already scream to redefine your team, its mandate, or point that there are no objectives behind incoming requests. Things like enablers or compliance must follow the same rules and contribute to the business value. Bonus: this transparency forces collaboration — no more customer-supplier relationships.
- Draft a customer journey — create a customer journey that your team supports, and plot your work across it. Is the journey recognized for its significance and impact on organizational goals? Is your work spread over too many touchpoints simultaneously, or worse, over too many journeys? Or you can’t find how the work you do relates to a customer journey? Caution: you need to be prepared to find some very painful lessons here.
A final comment
The Build Trap is all too common in many Product and IT teams: we expand our backlogs, managers ask for more features, and product owners write more user stories. We create complex processes to manage all these features, user stories, and dependencies. We feel we get a lot of work done. We optimize to deliver faster. But we forget that the goal is not more functionality delivered faster, but more customer value delivered earlier. Moving away from Product Management towards Continuous Solution Discovery is one way to avoid a Build Trap and to refocus on the customer value.
If you are working in a large, multinational company in a traditional industry, this will help you to find purpose for yourself and the team. If you work in a startup, it might look quite obvious but will help you refocus on what matters. This journey is not for everyone and not for faint-hearted. But once you start, you won’t want to look back. It will be epic.
Just start. Stay flexible.