Notes to myself: Lessons from a seasoned cloud software product owner

1.) It’s just software – everything is possible

Sure, but don’t think everything is viable at a reasonable cost.

• Is it worth assigning teams for multiple releases to it?
• Will it make your boat go faster?
• What do you have to drop if you are doing it?
• What do you lose if you are not doing it?
• Do you have the capacity to keep it running? You build it, you run it!

Nothing comes without a price and for some reasons some people think this is not the case for software. You always find someone to confirm that a feature is desirable. For the decision to leave out a certain feature you will be pretty alone. If you don’t manage to distinguish the must-have from the nice to-have you will never reach your target and end-up in a niche with your software. This is the opposite of what your current and your future customers need. Often software development organizations invest a lot of time to find out if something is technically feasible and on the way lose the focus for desirability from customer and user perspective. At the same time just looking on what is desirable is also not meaningful because your resources are always limited. Viability in terms of development resources, timelines and basic quality standards is not rarely the end point of many good concepts. A good product manager or product owner doesn’t give up – put the idea into the virtual fridge and wait. You’ll be surprised how quickly it can be implemented when the time has come – nothing is more powerful than an idea for which the time has come.

The challenge for product management, product owners and development teams is to keep the balance between desirable, feasible and viable with the given organizational constraints, timelines and quality standards. There is no single person or leader which can alone assess all three dimensions at a time. You need a team to get all perspectives into a common picture. Try to teeter-totter with a team and try to achieve a balance then you know how hard it is to counterbalance desirability, feasibility and viability.

After you have found this delicate balance the next challenge is to execute within the given constraints of your organization, unpredictable changes and surprises regarding complexity. Changing timelines, compromising quality standards or reducing your scope are the three potential options you have to deal with the unforeseen.

But in reality there is only one option: REDUCE THE SCOPE!

• If you extend the timeline of your current release you will have less time in your next release -> REDUCE THE SCOPE in the next release.
• If you change the quality standards to get more time you will have to pay the price in your next release to fix the issues you did not find ->REDUCE THE SCOPE in the next release.

So the bottom line is: TIME & QUALITY ARE FIXED by reducing scope you can deal with the unforeseen. As good product manager you need to plan for a scope reduction right at the start. Prepare a target scope but also think about your minimal viable scope and discuss it with your product owners.

2.) Standard software development ain’t custom development

Don’t fall into the trap to think developing standard software is just custom software development for more users. Developing standard software means to code for thousands of customers with very different usage patterns.

In standard cloud software development you work on 3 releases and a long term roadmap in parallel:

1. The productive release which your customers use needs to be kept up and running and sometimes needs correction.
2. The release which your are currently developing as the next productive release
3. The release you are preparing, for which you capture ideas, designs and check feasibility and viability.

It is paramount to keep your mainline running and with this also your customer base running and vital. Issues with your productive release have the potential to slow down and stop your current development and your preparation for the one to follow and finally your long term roadmap.

You usually have huge assets with your installed base and your platform. But you have to maintain them and this can turn into a limiting factor:

• Your customers determine what can be done. They want you to continue what you started and they use what has been delivered earlier in very different ways. You cannot simply throw that away and start all over again or ask them to work different. Even if the new concept promises to be 10 times better than the old you need to take your customers with you.
• Your reuse components determine what you need to use. Changing or even replacing a reuse component can get extremely expensive and risky.
• Finally your product standards determine what you have to consider. You can’t ignore them for new features, you have to go for the whole enchilada.

Only in rare cases you start on a green field. In majority of cases you start on a brown field as you have customers which use your software in absolutely different ways. Think about the difference between a service-centric and a product-centric business – both use ERP, CRM or HCM but in very different ways and configurations.

Following product standards, reusing components and using a basic solution framework is key for developing a consistent standard software which is continuously integrated in a central mainline system with customer-like configuration and data in the cloud. There are not only obvious reuse options like sharing libraries or a common user interface design but also internationalization, security, data privacy, country specific variations, extension points and integration into complex external frameworks (e.g. for generation of analytics or external integration APIs). Often you also have non-code procedures, configurations, content and data which easily gets overlooked if you just count the lines of code you produce and deploy.

In a custom project you can freely decide to leave out or ignore. There is always a shortcut possible if time is getting short. In standard software development you cannot easily find a shortcut as you are surrounded by efforts which you cannot ignore.

3.) Simple ain’t quick, quick ain’t simple – or – why NO is a good word

Simplicity it the ultimate complexity. If someone asks you to just build it simple: find out if its needed quick or simple – both at a time is a contradiction. Don’t fall into the trap to believe that an easy to use solution is also quick to develop. The opposite is the case. Simplicity comes if you have time enough to understand the complexities and to finally hide it. User experience is only superior if you have the chance and most important the time to observe people using the solution. You always can start simple on a green field but doing it easy with all the constraints you get from a brown field environment takes time.

When working on defining software requirements (also called requirements engineering) it is natural that the longer you deep-dive the more sub requirements you discover. This is good because it helps you to get the full picture. The problem is that at some point it’s getting difficult to differentiate the core from the spiral arms. “It’s easy to think I need something else. It’s hard to look instead at what to remove” is one of the key dilemmas of requirements engineering and software development strategy.

To overcome this you need to learn the art of saying NO: 

• NO is the most important word to turn strategy into execution. There is no execution if you cannot tell what to remove and how to focus.
• NO is hard to say but it is even harder to stick to it – especially if you are part of a team with many stakeholders.
• In big organizations many people shy away from saying NO. They say: “let me take that with me”, “I’ll need to find out who can work on this” or  “this is beyond my competence”….
• NO needs to be coming consistently from many voices. That’s why big organizations often fail to execute on visions.
• NO means often “I understand and I like to, but not now”.
• NO, means it is not viable due to missing capacity or technically not feasible.
• but often NO also means YES, it is desirable and it’s a pity that we can’t do that already at the start.

If you do not have a way to reject a good idea with a polite and well explained and defined NO you have a serious problem.

4.) Top-down AND bottom-up

There is no meaningful way to define a target from top and push it down to the whole development organization. Reliable plans are build by having two-way conversation top-down, bottom-up, top-down, bottom-up …..and so on.

There is also no meaningful way how software concepts and designs can be defined top-down and thrown over the fence to someone to execute on it.
Good concepts and designs incorporate input and feedback loops from both directions: top-down, from the product management vision to the developer AND bottom-up from the developers to the product manager.

Top-down AND Bottom-up can also be applied to the feedback channels which are needed between product management and customers or partners.
Only the interplay between product management, developers, customers and partners ensure good designs and finally deliver good software.

5.) Knowledge, wisdom AND power

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.

6.) There ain’t no truth, just perspectives

What is more important the customer buying the enterprise software or the employee using it? Is an effective business process more important than having users which enjoy working on it?

There is no answer to this question – it’s like chicken and egg.

As product manager you need to be able to change your positions to capture all perspectives otherwise you will only understand parts of the problem.
Here are a couple of them:

• Company, process, country, industry
• User, manager, employee, senior, junior, external worker, customer, partner
• B2B, B2C, B2B2C,
• Service-centric, product-centric,
• Marketing, sales, procurement, logistics, production, project,
• Finance, analytics, human capital….

The art of product management and product ownership is to capture the messages from all perspectives and decide which one to rate higher than others.
You need to find and listen the signals and filter it out from the background noise. Don’t think the loudest or closest signal is always the right one to follow otherwise you might end up not doing the right thing.

7.) 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 next, and the next. Nothing else.” (Beppo Streetsweeper)
• “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).

Many people think that life of a cloud software product manager is fun compared to on-premise product management as you only have one productive release at a time. In the old on-premise times you had to consider tons of releases and enhancement packs at a time. Well, the reality is that also as cloud product manager you are actively working on at least 3 releases in parallel and in addition continuously on a long term roadmap which goes into the future.

…and finally when you think you are done you have to start all over again.

8.) …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