This document summarizes learnings and best practices for agile enterprise cloud software product managers, chief product owners and product owners. I'll be extending and updating it over time so I would be keen to get your feedback. What are the questions puzzling you?
This is the full edition of my blog. A shortened version can be found in my LinkedIn profile.
Why is balancing desirable, feasible and viable key?
What is the difference between custom- and standard-software development?
Why does simplicity take more time?
Why are organizational debts even worse than requirements gaps or technical debts?
What are the skills for an enterprise software product manager?
How to find the right perspective and how to focus on the right requirements?
How to define & manage a roadmap and convert it into a backlog?
Only in hindsight plans appear good - not only markets are moving
"You can't connect the dots looking forward; you can only connect them looking backwards". There was no direct connection between the Newton, iPod, iPhone and iPad when Apple started with the Newton and when the iPod started the iPad was not in sight. Only looking back there seems to be a clear red line.
You won't find the perfect forward looking 24 month roadmap as you won't find a stable and predictable software market nor a stable software development organization. The dynamics in the software market are often obvious and very well tracked by media and analysts. The dynamics inside a development organization are rather hidden, impossible to predict but - equally important to understand as they can propel or stall your product strategy.
- When and how will the strategy of your company change? Will your company focus more on make or buy?
- Which leaders, skills, teams and resources will be available? Which platforms will be available for your product?
- Which products and components do you need to integrate or reuse? Which will be acquired, licensed or self-developed?
- When will a reorganization hit your team? What might be the impact to your product strategy?
The biggest mistake is to assume that the internal and external environment for your product will remain stable for 24 month. Therefore select the topics your organization has a chance to deliver like a juggler decides how many balls he can handle.
Be prepared to have a replacement in your pocket if balls fall down or strategy changes and don't flicker if it happens. Don't wait until you have the perfect vision, strategy and plan and don't expect that you will have more than 12 month to deliver tangible value.
Draft ideas quickly and challenge them with internal and external stakeholders. Don't be disappointed if some of your work will get harsh feedback. Yes, it is unprofessional to try to cross a river by jumping over it, a bridge is way more professional but do you have the time and the resources to build a bridge? Don't expect to get only tail wind, the head wind will shape your idea and connect it with others. Most important: Don't expect to be done with the first delivery - work just starts with the first release - after the release is before the release.
Oscar Wilde said “Everything is going to be fine in the end. If it's not fine it's not the end.” For a product manager that means to aim for the good in the first release but to plan to continue until it's at least good enough and to be prepared for unexpected interruptions and to start all over again.
Aim to finish something meaningful in the first release but don't think you can finalize in one. Don't get confused by management if they say "we are agile, we don't need a plan", "why don't we just do everything in one release?". Not having a plan and thinking that it is viable to do everything in one release is the opposite of being agile. Here are some golden rules which you should have in mind during agile backlog and roadmap planning:
- “Do it once and do it right and do it quickly” (Lee Child)
- “Be stubborn on the vision and flexible on the details” (Jeff Bezos)
- “Not having a plan is not agile”(John Yorke)
- "You build it, you run it" (Werner Vogels)
- "You must only concentrate on the next step, the next breath, the next stroke of the broom, and the ...
- "All our dreams come true, baby up ahead and it's out where your memories lie" (Tom Waits)
- "+1 release is the difference between an internal and public roadmap" (Jan Matthes)
In general a release starts with a long term roadmap on which you depict more or less concrete ideas and concepts you want to implement during the next 12 to 18 month.
The design phase needs to start early enough before the planned implementation time frame. As soon the first increments are delivered you need to take care for keeping it running which means usually that you have to reserve time for fixing bugs or closing gaps which might have been overlooked or postponed (here you can see how issues in one release can stall all following).
...and finally when you think you are done you have to start all over again.
...to be continued
While you are are giving me feedback and propose topics, questions and links to be added here are a couple of links which inspired me. Looking forward to hearing from you either if you like my thoughts or not - as Lenny Leonard said "Everybody makes mistakes. That's why they put erasers on pencils" ;o)
Message from Christian Klein
The life of a product manager in GIFs
Not having a plan is not agile
You can't connect the dots looking forward; you can only connect them looking backwards.
We seek, not to know the answers…but to understand the questions
- SAP Managed Tags:
