This is the fourth post of a five-part series I am writing with the aim to help a product aspirant enter the world of Product Management.
In my last post, I broke down the discipline of Product Management into four parts with an aim to help Product Management aspirants understand their career trajectory within a company or in general. In this post, I will be talking about the life journey of a product feature, from ideation to abandonment, to help a Product Management aspirant get a 360 degree perspective on what the role of a Product Manager involves.
T – 30 days
It is said that necessity is the mother of invention. That is literally the case where a product feature’s birth is involved. It all starts with some level of discomfort.
Some employee in the company faces a discomfort in achieving one of his daily tasks – maybe the user base has increased and he is not able to manage it with the old processes. Some executive in the company looks at an excel sheet and thinks that the company is losing too much money because of, say, high numbers of product cancellations. Or maybe a competitor launched a product feature that is causing the customers to leave the said company’s product. Someone looking at the marketing conversion funnel noticed high drop-offs at a certain stage and felt that optimising that might help him achieve his quarterly target. Or it could be a 100 different reasons from a high number of customer complaints for a common problem to a new feature being demanded by a majority of the users surveyed the previous week. The point is – it all starts with some level of discomfort.
Now, this discomfort is brought to the notice of the Product Manager; or maybe the Product Manager is the one who notices it first. This is the point which starts a chain of events that might lead to the birth of a new feature.
T – 25 days
It’s time for the Product Manager to mull over the problem statement. He goes and talks to customers or internal stakeholders who reported the discomfort and then those who are actually experiencing it; all with a single aim – to make sure that he has identified the ‘root’ problem statement. If this stage is taken lightly or the Product Manager doesn’t spend enough time on this, then the product features born are fragile, distorted and meet their end pretty quickly.
Once the Product Manager has identified the core problem statement, he decides if it is worth solving. Is the discomfort really a big one or is it kind of exaggerated or worse, just made up? Would solving it actually add significant value to the customer and/or the company? Would not solving it impose a significant penalty on the customer and/or company? Is there a way to solve this problem with a minor tweak in processes or through any activity that doesn’t require product changes – say changing a vendor, negotiating better price from an existing vendor, getting a third party software to solve the problem, hiring an extra employee, changes in content, graphics, call-to-action button, etc?
Basically, if there is a way we can get similar value-addition from a method that doesn’t involve product changes, then we would go for that over changing anything in the product – whether that means adding or removing. Once the Product Manager is convinced that solving the problem statement will provide significant value and a product level change will give much more ROI (considering time, money and effort v/s value) than a non-product level change, the seeds of a new product feature are planted.
T – 15 days
If the Product Manager has some prior experience, he might propose a solution based on that experience. However, that might not be the best solution in all cases.
If the problem statement requires a highly technical solution, the Product Manager discusses the same with developers and engineering managers and takes their advice on best way to go about it. If the solution requires design level changes, the UX lead might be consulted. It could be that the Product Manager and UX person organise a design sprint and choose the solution that is received well by the actual users of that feature. Sometimes the problem is totally business related and hence requires a buy-in from the senior management.
So, there can be multiple ways a solution could be finalised. But once it is, the Product Manager is responsible for converting that theoretical solution into an active product feature.
T = 0 (aka birth of the product feature)
When a particular solution is identified, the Product Manager, in collaboration with the relevant team, hashes out a basic outline of the solution. It may or may not include a prototype of the solution. Sometimes it is just a basic excel sheet with ‘if-then’ conditions written for when to show a particular CTA to a user, etc.
The Product Manager puts the solution into words in the relevant PRD (Product Requirements Document). If the feature is small, it might just be a paragraph in an existing PRD for a bigger feature. Sometimes the feature is so huge that it requires a complete PRD just to detail it properly. The PRD is run by the relevant teams and the Product Manager makes sure that broad consensus exists regarding the feature.
T + 15 days
Small features might take less than a day to be frozen. Big features, sometimes, take more than 30 days to get everyone’s go-ahead.
Let’s take an average of 15 days to say that this is the time when the newborn feature is introduced to the developers. A proper design and PRD handover take place where developers who are working on the project are informed about the 5Ws (What, Why, When, Where, Who) and the test cases (how the feature should behave or not behave once it is released).
Along with the engineering manager, a proper release schedule is decided for the feature with deadlines for when the development will end when the testing will start, when the reported bugs will be fixed and the final release date. Then the whole timeline is divided into measurable sprints (usually 15 days long). Once developers are satisfied, development begins.
T + 30 days
Sprint 1 ends. One part of the product feature is rolled out. It might not be customer facing yet, but most teams follow Agile methodologies today for software development – meaning that we build incrementally and iteratively. So, rather than building a big feature in 6 months and releasing all at once, we break the whole thing into independent parts that can function on their own (a bunch of User Stories) and are quickly ready to be reviewed and iterated.
The Product Manager makes sure that the release timeline is on track through daily scrum meetings and discussions with the relevant engineering manager working on the project. In case there is a delay, timelines are adjusted accordingly, or small parts of the features are dropped to make sure that release is on time. After each sprint, the progress made is presented to the Product Manager and relevant stakeholders in a meeting, and post-approval it is released.
T + x days
After ‘n’ number of sprints, the development is complete and the entire feature is out. It is not necessary that the customers get to use the feature only when released completely. They could be using it since the release at the end of sprint 1 itself. Each subsequent sprint cycle release only makes the feature more robust and brings it closer to what it is intended to be.
Launching a feature is itself an art and involves a lot of steps that we will skip and just assume that after a lot of drumming and chest-thumping, it was declared to the world that a feature has been released. This might be as complex as a full-blown Press Release with the CEO himself talking about the new launch, or it might just be something on which a mail is sent to a particular department that is going to use the feature and probably requested it in the first place. So now that the feature is out there, let’s give this feature a name – Mr. Feature.
T + y days
Even after the final release, things sometimes go wrong. Mr. Feature, which was once all shiny and valuable, might not be the same anymore and there could be multiple reasons for it. This phase in a product’s cycle is about supporting the product. One fine day another release was made that caused Mr. Feature to perform in unintended ways (a.k.a. become buggy) or maybe another feature was removed that had some dependencies on Mr. Feature and this caused the buggy behaviour. It could also be that when the feature was made, we underestimated the number of users who will use it or didn’t plan all the use-cases and now the feature is not able to scale up to these many users or use-cases.
This is either reported by the test team in their periodic review, or it is reported by some team member who just discovered it while using the feature himself. In case of customer-facing features, these complaints might come from the actual customers of the product and be communicated to the Product Manager via the Customer Experience team.
The Product Manager tries to understand the root cause of the bug and, according to priority, schedules the fix for the next release cycle – it could be added in the current sprint if it is high-priority or even subsequent sprints. After the bug is fixed and released, Mr. Feature lives to see another day, albeit in a reformed form – Mr. Feature 2.0 – thanks to the Product Manager and the engineering team. Kudos!
T + z days
It is said that all good things must come to an end. Sadly, that is the case with Mr. Feature too, no matter what its version is – maybe Mr. Feature 9.263.75! That means Mr. Feature has lived a long and happy life, but now the end of the road is here.
It might be due to various reasons. A new feature came along which made the need for Mr. Feature altogether redundant. It might be something extreme too – like the company decided that although the feature was adding value to its users, it didn’t make economic sense for them any longer.
No matter what the reason be, it is communicated to the Product Manager (or he is the one who starts the discussion) that Mr. Feature’s services won’t be needed anymore. Now, as heart-breaking as it is, the Product Manager has the duty to lay Mr. Feature to rest. Although, before that, he needs to make sure of a few things like informing the users who were using Mr. Feature that it won’t be available from a certain date, the new feature is working well before removing Mr. Feature, no other flow gets impacted when Mr. Feature is gone, and so on.
So, it is time to say RIP to Mr. Feature. In your product management career, you will have to do this multiple times. But remember, the end of one feature is the beginning of another and the cycle continues. Such is the product management life!
If you enjoyed this post and have any questions regarding product management, comment below!
Read the last blog in this series to know about the 5 Challenges for a Newly Recruited Product Manager.