Introduction
I have spent most of my 30+ years in the IT industry working with Product Management or related activities, so I thought I would share what I have learned with you who might be interested. I wrote this article because I have seen too many organisations that don’t do “proper” Product Management, as I see it. Typically these are former start-ups that never grew up, so to speak. Because of this, they risk developing the wrong products for the wrong reasons.
The Who, Why, What?
If you are developing a product, the first basic questions you must answer are: For whom, and why?
Assuming your organisation has a Business Plan in place, and has some idea of why they exist, you can start from there.
- Enterprise business planning solutions in NA and EMEA?
- Dog food dispensers in Eastern Asia?
So you begin with that and define it further:
- Markets – Countries, tiers etc. This is useful further on as you try to calculate the addressable market size in your Business Case calculation.
- Customers – organization types, size etc
- Users – Personas, position etc.
What are the problems, issues you are addressing? It is important to define this before you define the solution. Remember the old story about drills: The customer doesn’t need drills, they need holes. The drill is just a solution, there could be others.
You can define each need as a use case, for instance:
- The bowl must hold enough food for 5 days, because the owner will be working away-from-home during week days.
- The user needs a report that instantly shows the risks in the yearly budget.
This is where you can start using the new Generative AI services that have recently been introduced. I have tried it and it can be surprisingly useful.
There is of course a chance that you already have a product on the market and that you are planning to address another similar market, or add a new major feature. The process is still the same, you should do this so you don’t forget why you started.
This answers the “Who” and “Why”, now let’s look at the “What”.
Here is where you define how you intend to meet and solve the customer’s need. Avoid going into implementations, and continue to work on the Use Cases instead. This is to avoid lock-in on certain technology or products. If you are using Jira or similar, you can use the Initiative and Epic templates for this. This information must be processed further later in order to define the implementation and make cost estimates.
Business Case
Is it worth developing the new product? Will it be profitable?
If you don’t know the answer to these questions, or at least have an estimate, should you really start the development?
You must also compare these numbers between different potential products. Developing Product/Feature A will use the resources that could be used for Feature B. If the profitability is not high enough (see PLC), the company should maybe invest in crypto currency instead or put the money in the bank?
Ultimately, the Business Case is what you present to the stakeholders (and those with the money) for a go/no-go decision.
So what do you need to know, and how can you find out?
Revenue
For the Revenue, this is where you use the definitions of the “Who?” you have worked on initially. To get financial numbers on market size, etc. you can use the Market Research organizations for your target market. Maybe you already have the numbers in your organization. From here you define the Total Addresable Market (TAM) and estimate your potential share of thet market.
Then comes the critical question: How much can you charge for the product? I can’t help you here, but try looking at the cost of alternative solutions, perhaps from competitors. Remember to relate this number to the expected volume and the Market share you have assumed.
The numbers you arrive at will be extremely unsure, but at least they are derived from some kind of fact, not just wishful thinking.
Gross Income
How much is the solution worth to the customer, and how much income can it generate?
The simplest model is to take the revenue and deduct the Cost of Goods Sold (COGS). For Software or a Service (SaaS) product, the COGS are a lot simpler (even though it may be hard enough) to define than for hardware products. A complete calculation for the income and profitability of the product should be made using something like what I describe in the Product Life-cycle Calculation chapter.
Development cost(s)
How much will it cost to develop the product….and how long will it take?
You will not be able to answer these questions until you have made a (preliminary) development plan. I will cover this in the development section.
Product Lifecycle Calculation (PLC)
This is a calculation of costs, income and profit over the life cycle of a product, from development to termination.
Below is an example I have made, the numbers are just made up. As usual, the costs come first and the sales later. While the product is on the market, there are also costs like support and maintenance to consider. Maintenance has a tendency to lock up way too much resources. In the end, this means that it will take a long time to break even. This is seen in the graph below as the purple line (Accumulated Result)
Also, to be more correct, income that comes in the future is not as valuable as money in the pocket today, should be reduced by some interest rate.
Finally, the profit from this product must also cover the other costs of the organization (besides development) plus the expected return by the investors.
To make the graph, I used this table:
Explanation:
- Price = 10 / Unit, going down after a while
- Revenue = Volume * Price
- COGS = 20% of revenue
- Development costs = made up by me
- Maintenance = 20% of revenue
- Support = 5% of revenue
One thing to consider is that some cost are constant regardless of volume.
In my example I’m using a SW product. If it had been a HW product things would have been 10 times more difficult:
- Material cost that vary with volume and time
- Inventory capital costs and potential write-offs
- Transport costs
- Warranties
- Customs
Defining the implementation
In order to make a business case, you must estimate the development cost and time, and to do that you must have an idea of the implementation.
Unless you have developed a similar product before, I suggest having a pre-study, perhaps with prototyping. Specially consider the critical or new/unknown functionality and try to make a Proof Of Concept.
Break down functionality that has been defined in the market requirements or Epics/Use Cases before.
Write simple user stories for each. The outcome should be an implementation proposal and an architecture. This will be a back-and-forth discussion between Product Managment and Development lead and architects.
Agile/Scrum seems to ignore this phase, shunning plans, and suggesting you “just do it”. I strongly disagree. If you can’t make a business case or a cost/time estimate, who would pay for the development?
Estimating cost and time
Don’t expect to get this right the first time. The purpose is to get a “guesstimate” for use primarily in the go/no-go decision. For each Epic/UseCase/User Story make a “SWAG” (Scientific Wild Ass Guess). Yes, it will be wrong, but it is still useful.
My suggestion is, if you’re using Scrum or similar, let each team involved estimate the “points” for all known User Stories. Then add them up and compare them with the known Velocity (“development speed”) for each team. Map this out in a Gannt chart style plan:
This is not to replace Agile/Scrum style development but to help Product Management have at least something to compare the progress to later on. As the development proceeds, you may see that your predictions were wrong (probably too short), so you can update the plan, and adjust the estimates based what you have learned. You will likely discover new things that must be added as well. This way, you have something to report to the stakeholders.
Verify/Beta-test
Once development is getting close to release (MVP), you must verify internally that the product meets the requirements. For functionality (and deployment), you should engage selected customers to help with testing, beta test, PoC.
Also make sure the development teams verify non-functional requirements such as performance (critical components should be tested for this way earlier of course)
Market introduction
There are many things that must be done for a successful market introduction, to be able to actually sell the new product. That was the goal, after all. I believe it is the responsibility of Product Management to make this happen. Here are some of the things that you should initiate, well in time for release (why hurry with the development only to realize that you cannot sell the product?).
- User Documentation – Use tech-writers or similar. Make sure you understand it yourself, and have it reviewed by SE’s, support etc. This should be used in customer beta tests as well.
- Support – Support organization must be trained in the product. Throubleshooting guides written etc.
- User Training – If you provide user training, this must be prepared.
- Marketing material, presentations – Write and review
- Web site – Obviously
Sales Support – Sales Engineers, Solution Architects should be trained. Actually, you should engage them throughout the whole process to help with requirements, documentation and reviews.
Summary
In this article I have outlined the different activities I believe must be part of proper Product Management during the product development process. It may seem like a lot, but doing the proper ground work will reward you in the end.
By the way, Product Management can be responsible for other things as well such as Product Vision and Roadmaps, competitive strategy (Time-To-Market!), positioning, sales support, customer presentations, defining industry specific solutions, competitor analysis etc. There is no end to the fun.
Good Luck!