As a Software Product Manager, I have been making lots of decisions about the products — conscious ones, unconscious ones, quick ones, and the ones that took ages. Some good and right decisions and inevitably wrong and bad decisions as well.
The Software Product Manager is the decision-maker for the product. The SPM’s decisions shape the product, gain competitive advantage, and make it successful or unsuccessful in the end. So, right or wrong, bad or good, each decision needs some attention. And indeed, the Important Decisions or Important Product Decisions (IPDs) need much more attention.
If you are already following a formal decision-making process, keeping a decision journal, that’s great. If not, Farnam Street Media has excellent sources to start. Decision-making is not a gut feeling based process but has really neat methods. These methods try to avoid making decisions in the dark, understand the playground, and eliminate the wrong ones. Of course, nothing is bulletproof, but there will be fewer wrong decisions.
More importantly, using a decision making process simplifies the communication of the decisions as well. The communication of the decisions— common understanding of “why”
Important Product Decisions (IPDs)
The Software Product Manager makes lots of decisions, but some of them are IPDs. IPDs may be Important Business Decisions (IBDs) or Important Technical Decisions (ITDs). The licensing terms, target market, channels to use, business model all are IBDs. The database type, the standards to follow, or the execution environments are ITDs.
Why are these decisions important? These decisions affect the product in a way to gain technological and commercial advantage. They are part of the product’s innovation and shape why our customer selects our product, not the competitor’s.
If a decision is not fulfilling these aspects, provide an advantage and results as a criterion of selection; yes, that’s a decision and maybe a perfect one, but it is not an important decision. The software product manager’s responsibility is to focus on making the right Important Decisions.
I advise you to keep a decision journal that enforces not only to write down the alternatives of the decision but also to record your mood and expectations, and very handy to revisit your decisions after a time (i.e., six months.) Business or technical, your decisions need clear reasons and justifications. The decision journal is a great way to write them down.
After the decision is made, the SPM must formalize it in a communicable way. Some examples are as follows:
- We will apply transaction-based licensing because our customers earn money from the transactions they complete. A user-based license cannot scale properly.
- We will apply discounts to students because we want to build a loyal user base for the future. It is cheaper than running targeted advertisements to the students, and they can’t afford the current fees.
- We will use Xamarin because we don’t want to make development on multiple platforms. Native applications need maintenance teams of their own, and we don’t need any native application features.
- We will use Redis as our distributed cache since our high availability feature needs built-in replication. Redis is open source, and the company already has the know-how.
The first sentence of each decision includes two parts, the decision itself and the target to achieve. The other sentences justify why we made this decision among the alternatives. These examples try to create business and technical advantages (so they are important decisions) such as;
- A licensing model supporting the pay-as-you-grow model and optimizing the company’s revenues.
- A loyal customer base which can advocate the product and continue to use it after their education based on familiarity with the product.
- An environment minimizing the support and maintenance efforts and costs.
- A technology supporting a differentiating feature (high-availability) and parallel with the capabilities of the company.
An important decision may be on different levels. An Important Business Decision is expected to be mostly on the Context level. There may be container level decisions as well, but they are less likely (e.g., using a specific database, not because of capabilities, but the price, support or partnership.)
You may think that Important Technical Decisions mainly focus on component and code level in contrast. Indeed, this assumption is wrong. Most of the decisions taken on the component and code level are not important decisions. Indeed the majority of the ITDs also reside on the container level.
The SPM mainly focuses on context and container level important decisions and contributes component level important decisions. It requires active involvement in the decision-making process. The SPM ensures any important decision really creates an advantage and is followed in the product’s whole life cycle until a contradictory decision is made.
It is not possible to make all of the decisions on day one. Indeed decision making, revisiting, and changing is a natural process within software product management. But the software product manager must well understand and express the decision’s reasoning, ensure the teams follow the decision, and continuously judge if the decision helps to reach the expectations or not.
I have tried to talk about the C4 model and Important Product Decisions that I will frequently refer to. I will start to discuss structured software product management methodology with requirements and requirements analysis in the next post.
