Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

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?

  1. Why is balancing desirable, feasible and viable key?

  2. What is the difference between custom- and standard-software development?

  3. Why does simplicity take more time?

  4. Why are organizational debts even worse than requirements gaps or technical debts?

  5. What are the skills for an enterprise software product manager?

  6. How to find the right perspective and how to focus on the right requirements?

  7. How to define & manage a roadmap and convert it into a backlog?

This time I will reflect on why 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.


…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