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.