- SAP Managed Tags:
This document is part of a series of posts which I started in December 2020 to remind myself of experiences and best practices as agile cloud software product owner and manager. I’ll be extending and updating it over time so I would be keen to get your feedback. What are the questions puzzling you?
- 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?
Product management and product owner expertise is build-up in years not in month. A good product manager has knowledge and deep hands-on insight on the product, the development organization, the market and the business domain. But most importantly is the wisdom to distinguish the desirable from feasible and viable. Finally you need power to inspire, to decide and to go the distance because this is a marathon executed in sprints.
Knowledge and wisdom are nothing without power. For a product management team lead that means you need to be able to step back and rely on the judgement of product management experts even if you might have sometimes concerns.
For a product owner or development lead that means
to have lots of time to listen, to debate, to adopt, to adapt and sometimes just to trust. Before starting the implementation product managers and product owners need to be on the same page on the problem statements and the desirable solution.Understanding a business domain needs the ability to look on a problem from many perspectives (see Chapter 6 for more details). The product owner is usually specialized to deeply understand and explain the feasibility, viability and implementation perspective of the solution together with a scrum team.
The product manager more focuses on problem statements and the desirability, his focus is the bigger picture as usually he is working with multiple product owners and teams which specialize on sub topics of a certain domain.
- Product knowledge: What can your product do in which domains? Can you use and show it on your own?
Don't believe that talking about the software and its direction is enough. If you can't use your software and show it's merits, who can? - Organizational knowledge: Who are the leaders but more important who are the developers, designers, architects, sales people, consultants?
The challenge is not to describe a common vision but to find a way how to execute it in the given organization and its constraints. - Market knowledge: Know your customers, partners and competitors. Know the influences like analysts, media, macro economics and trends.
- Domain knowledge: This is probably the most complicated to obtain. What are the business processes? How do they differ in industries, countries and business models? What are the user roles? How is the day-in-life looking like? What targets do the employees have? How are managers tracking their team? How do people use software? What processes are time consuming, routine and what are unplanned activities?
The wisdom of product management is to know that you know nothing. Let's face it: Software product managers, product owners, UX designers and developers usually build software they do not use themselves. They are expected to own a kingdom they do not live in. How to deal with the situation that you work with a large network of cross functional people which expect from the product manager to have the ultimate knowledge?
- Cobbler stick to your last. Stay calm and deep dive on your software and those of your competitors
- Grow from where you are but don't stay where you are
- Keep your eyes open to change in work style, micro- and macro-economics
- Listen often, continuously and long to customers and partners which use your software daily. Yes, this is painful because you'll hear mainly complaints but it is the only way to understand your software and the people using it.
When you are pushing your visions and ideas - the more you love them the more you need to question them. At the start they are never good, they evolve over time and grow by being questioned. You have to say good-bye often like a gardener which is cutting the tree to give it the focus which is needed to grow the right branches. The wisdom to distinguish the idea which is achievable and the idea which is possible but only at a very high price is hard to get.
A good idea does not find its way easy or in one good meeting. It needs to grow from a small plant to a tree by talking, repeating but most important by listening to the ones which might use it, which might develop it, which might produce it and which might sell it.
…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
