We are at that point in which there is software in places where a few years ago, I never imagined that there would be need and usefulness in having a software: TVs, refrigerators, stoves, cars, watches, glasses, clothing, locks, tables, chairs , medical equipment and so on. Not to mention the most obvious, the phone that is in our pockets or purses and from which we are becoming increasingly dependent.

The ubiquity of software is now a reality; the software permeates numerous activities and objects of our daily lives. I think one can say that 100% of the population has their lives affected by software, and much of this population has frequent contact with software. According to the report We Are Social 2015, even underdeveloped regions like Africa already have more than 25% of its active population on the Internet.

Even with this evidence that the software is part of the life of every person on the planet, I still have the impression that we do not give it due attention and care. Think of all the times you used a software over the past seven days. Have you had any frustrating experience with it? I’m sure you did.

I have frustrating experiences with software on a daily basis. Even software made by experts on the topic of software development Ð such as Google, Facebook and other companies that were born and raised making software and that are often cited as references when we discuss software development process Ð cause us frustration.

Why does this happen?

Software development has evolved a lot over the years. Talking about processes, we had waterfall where each phase of the software development occurred sequentially. The distance between the need that generated the demand of the software development and the software itself was huge.

At the beginning of this millennium we begin experiencing with agile methodologies, which turned the software development process into a cycle with short interactions that promote continuous feedback. This helped considerably to bridge the gap between the need that generated the demand of software development and the software itself.

In terms of the aspects taken into consideration in the software development we also evolved a lot. In the beginning software was developed by teams composed exclusively of software developers. In fact, it was not uncommon these teams are composed of a single person. We increasingly see multidisciplinary teams working together in the development of software; which is very good because it brings new insights to the software being developed.

On one hand, the concern with the user, her goals when using the software and her interactions with this software are taken care by user experience professionals, or UX.

On the other hand, the concern about software operation, i.e., where this software will run and what performance and availability it needs to have, brought system administration professionals (SysAdmins) closer to the software development process. This proximity between software operation and software development is what gave rise to the term and DevOps culture.

So we deliver software more frequently, and brought UX and SysAdmins into the software development process; but is this really enough? How do we tell the world, or better, for people who can benefit from this software, that this software exists? How do we take care of your legal issues? When a user has a problem with the software, how do we help her? How do we manage the return it will bring? How to ensure that the software meets the objectives of its owner while it also meets the needs of its users?

Software product management

Thinking about these issues, some companies that are considered experts on software development began to adopt a new expertise in its software development process, Software Product Management. This role aims to ensure that software being developed meets the objectives of its owner while it also meets the needs of its users.

In addition, a person in this role has to consider all aspects of the software that I mentioned earlier. Some agile methodologies such as Scrum, have the role of the Product Owner, whose main responsibility is to prioritize items to be developed. In a way this is what a Software Product Manager does, but there’s a little bit more to be be covered by this role.

That’s what I’ll talk about in this book. 🙂

Who will benefit from reading this book?

This book is recommended for anyone who works with software. It is for people who are product managers, since every product manager knows that there is always plenty to learn. And even those who have good knowledge of all the topics presented in the book may benefit from reviewing the topics.

This book is also recommended for anyone who is willing to get into the product management career. I believe this book can relieve some of the anxiety of those who are considering becoming product manager, and is not sure what she will do and what other people expect of her.

I believe that even people who are not and are not planning to become product managers will also benefit from this book, understanding what a person in this position does in the software life cycle and how a product manager should relate to other areas.

Note that I said this book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

This book does not pretend to cover all the topics extensively. If it did so, it would probably have to be in a collection of books. My goal is to talk about the main topics related to software product management, deepening on some specific topics and providing various additional reading suggestions.

In some places the book will refer to Agile software development and the role of PO (product owner). I believe that the knowledge of software development process and the different roles involved in this process is not necessarily a prerequisite for reading this book, but it is certainly a knowledge that will help increase the chances of success of your software. If you want to delve into the subject, I recommend the book “Learning Agile: Understanding Scrum, XP, Lean, and Kanban” by Andrew Stellman, Jennifer Greene. In addition to explaining the principles behind agile culture it also presents Scrum, XP, Lean and Kanban, the four most popular agile methodologies and how to spread the agile culture throughout the company. Recommended reading.

Book structure

I wrote the book with the following structure:

• Part I – Definitions and requirements: to start I will define some keywords like software, product, platform, product management, among others. In this part, I will also talk about the characteristics of a good product manager, and I will give some tips to product managers on leadership and organizational culture.
• Part II – Life cycle of a software product: in this part of the book I will describe the life cycle of a software product and the stages of this cycle: innovation, growth, maturity and end of life. I’ll talk about what is innovation, how to find a problem to solve, how to find out if it is indeed an opportunity to be pursued and how to get return from your software product. In the growth phase, when the product was developed and launched, we should worry about how to manage the product during its growth, i.e., how to manage feedback? What is a roadmap? How to prioritize the demands? What to do with special requests? How to say no? Metrics to track? After the growth comes maturity. Why maturity happen? What to do if the product reaches that stage? After maturity, or when the product is developed but does not find enough demand, comes a phase named end of life of a software product. We will see how to detect and what to do in this phase of the cycle. In the end, when we know all stages of a product’s life cycle, I’ll show the difference between startup and software product management.
• Part III – Relationship with other areas: how product managers relate with all different business roles, such as engineering, UX, product marketing, project management, operations, sales, legal, finance, HR and administration?
• Part IV – Product portfolio management: why some companies decide to have more than one product? How they manage this portfolio of products? Why other companies prefer to focus on a single product? Focus or diversification, which is the most appropriate strategy? How to organize the product development team according to the chosen strategy? These issues are what I consider advanced topics of software product management, and that is what we will see in the chapters that make up this part of the book.
• Part V – Where to use software product management: does software product management can only be used by companies that sell software products and only in the development teams that develop software that are commercialized as products? Or would other companies benefit from treating their software as a product and using the product management techniques to increase the chances of success of their software? And where should we put the software product management in a company? In marketing? In the technical area? These will be the themes of the final chapters of the book

This sequence has a logical order and some chapters reference topics covered in previous chapters. For this reason, I recommend the sequential reading of the book. However, the chapters can also be read independently. If you are very curious to read about a particular topic, feel free to jump straight to the relevant section.

Enjoy!

Product Management: Delight your customers with your software

Paulo Caroli is translating my book on Software Product Management that I wrote in Portuguese and launched in Brazil last year. Our main objective with this translation is to increase the number of books on Software Product Management available for readers all over the world. The are not many books on the topic, even in English, and we believe the content of this book is useful for people in the software industry not only in Brazil but anywhere in the world.

We are working on the first chapters but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedback is always welcome!