I’ve written here about the process of product management, where I emphasized on understanding the user’s problem. Recently I was made aware of something deeper and helpful. Yes, understanding the pain points are important but when we start solutioning, we should consider the scope of the product that is larger than the pain point.
Scope = pain point + value = end-to-end value.
Know the pain point, but don’t focus on that alone. Pain point can be the spark that starts your thought process but it should not be the only thing you solve for. You, as a product builder/visionary, needs to think beyond your customer base and think of the future customers; think beyond the pain point and think of the end-to-end value. When your current customer tells you about the pain point, they might be just talking about part of the whole value, it’s your job to figure out the rest. Because your next new customer will not see the full value if you only solved for that one pain.
And sometimes this can open up a new market for the product. Example, Instead of thinking of Uber for Drunk people, think about Uber for Party Goers.
Nothing takes the fizz out of feature like not shipping on time. The more the delay the more frustrating it gets for everyone – the team, the stakeholders and the customers. That doesn’t mean, you deliver something haphazard just because you are nearing the deadline. The ideal is deliver what you promised and on time. So how do you go about ensuring that you deliver on time, or at the very least not frustrate the customers.
Break down the feature into smaller chunks or user stories or work items.
Put ETAs for each of the above items and call out owners.
Check periodically – daily stand-ups are very helpful. Keep track of ETAs and check in the mid point and 75% point. Say its a 5 day work item, then check at 2 day and 4-day mark with the owner if the item is going per schedule
Following the above steps, usually you get an idea of slippages. Once you spot a slippage, see if any remediation steps can be taken. If nothing can be done to stop the slippage and you are sure you are going to overshoot the ETA, first and foremost, inform the stakeholders. They might even find a way to put more resource on the problem and help you if it is a business critical feature. As for the customers keep them posted through forum posts or emails (if the count is small), better still you can put out the mocks to instill confidence that the feature is being worked on and call out the new ETA. Better still, you can call out the chunks that you will not be delivering in v1 on the time of earlier ETA, but you are still open to release as a private beta to your customers on demand. You can read more about this order words < mocks < Beta < product here.
That’s the order in which you can create delight when you are talking about a feature to your customer/prospect. Mock screens trump words and working product trumps mocks.
If you show your prospects/customers a slide deck about the feature you are not gonna impress them, that should be the last resort. Mocks are one step better than words, at least then your customers can see how the end product is gonna look like, you might be describing a elegant horse and she might be imagining a donkey! Without the mocks the customer is not gonna understand the value well. With mocks, at least you got them to see what you have envisioned, this also helps you validate the user flow that you thought was the right one. The best conversations with the customer, which will deliver delight, is by showing a working product, it could just be a beta activated in your account.
Having said that, if you want to validate something quick, then mocks are the right middle ground between you describing the feature with just slides or words and going the whole 9 yards to build out the entire feature just to get validation.
Another lesson I learnt this week, was when you are talking to a prospect, always keep showing how the value is delivered in the product even as you talk about different value propositions in the product.
^ That is what I heard from the CEO of the company I work for, when he was articulating what a Product Manager should do. In my opinion it is the best articulation of what a product manager does.
The more I thought about the statement, the more revealing it became. If you were to deconstruct the statement, you’ll notice that there are three parts to it:
Know the problem
To solve problems, one needs to know what the problem really is. You truly know the problem when you talk to customers, when you have spoken enough that you feel the pain that they face. One of the best things a product manager can bring to the table during problem-solving is the correct understanding of the problem in a way that they are able to explain to the tech and design folks in the team.
Frame the problem
That also involves framing the problem well, so that the scope of the problem is well defined. A lot of times you understand the problem but frame it open ended, this leads to scope creep and thus will delay shipping. Break the problem down to specific issues that you want to fix and frame the problem correctly.
Own the problem
A lot of times, I have heard the problem from a pre-sales or a support person and have been tempted to brief the team based on that. It has almost always left me in a place where I’m unable to answer some of the questions that my team might ask regarding the problem. But whenever I have spoken to the customer and heard the problem stated in their own words in context with their organizational workflow, I have had a better grounding in the problem. The thing that has worked for me in the past is to talk to more customers. That is the best way to peek into the customer’s world. Sometimes even seemingly unrelated problems will start to relate in your mind and then you can think of a wholesome solution that will fix these similar problems.
Now that you know the problem like the back of your hand, you need to prioritize. Resources are never infinite, therefore you have to pick the right problems in the right order to fix. This is where the Product Management cliche is actually true — ‘‘Product management is part art and part science”. You can make this a little easy by using the Urgent-Important matrix.
To understand the urgency, try answering this question: why should we build it now and not 6 months down the line. The answer could lie in a competitive advantage, or reducing the gap between you and the competitor to whom you are losing many deals. By the way, not everything has to be with respect to what you see in the rear view mirror. You might even see a wave the market is catching on and your product will do good to adopt that.
To understand importance, try answering: Does this problem align with the vision of the product? Fixing this problem will help a bunch of customers or just the two who are complaining?
The order of priority should be:
Urgent and Important — no brainer. This is the first thing you work on.
Important and Not Urgent followed by Urgent and Not Important — There is usually a lot of tension on which of these two quadrants you should place a particular feature. Here is how I work — I associate Importance to the long term vision of the product. Some customers or A customer might want a feature now, you have to see if it aligns to the future vision of the product. If it does not, then put it in third quadrant — Urgent but not Important. Always remember: if it is important enough, you will surely know. The drip of requests will become a stream of votes in the forums and eventually a torrent of support and pre-sales folks pouring down on you to get it done. So, don’t worry too much. Decide fast and move.
Not Urgent and Not Important — no brainer again. Don’t bother working on it.
When your users have adopted the product en masse, then you can say that you have built it in a meaningful way. While you are solving the problem, think about how it benefits the user. How usable(ease of use) and useful(solves a pain) is the feature? Shipping the feature is only half the job. Ensuring users know about the feature and adopt the feature is the rest. One of the guiding principles for me comes from BJ Fogg’s Behavior Model.
To get users to adopt a behaviour, the solution should factor in the following:
M — Motivation. There should be some motivation for the user to do that behaviour. For example, Using this new feature X you could alleviate this pain point Y.
A — Ability. They should have the ability to use the feature or turn on the feature. Do the users have to jump through hoops or it’s simple to activate or use that feature. As you can see in that graph, if the motivation is high, users will be OK to jump through hoops to do an action (eg. IRCTC, banking sites). Lot of times in Enterprise software, there are users with different roles. A user (Phil) with one role would be the one affected by the lack of x but it might be another user(Emily) that has the permission to activate x. So be mindful of these when you design the solution. For example, you could have an option for Phil to shoot a mail to Emily requesting her to activate the feature.
P — Prompt. Prompt is when do you choose to educate the user about this feature. Do you choose to do so when the pain is most felt, with an easy way to turn it on or do you choose to send an email about the feature and expect them to try it out. The latter works poorly. Prompt them when they are hurting.
Example: Swiggy(food delivery app) sending a notification (prompt) to order dinner(motivation) from your favourite restaurant during a day-night cricket match with a single click (ability) to its user base.
So next time when you start to work on a problem, ask yourself if you are solving the most important problem in a meaningful way.