Scope = pain points + more value 👍

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.

Photo by Jon Tyson on Unsplash

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.

Sharing Knowledge / Gossip🤫

When you become the person who knows things, then you get a certain amount of Klout. But the problem is others should know that you knew it first. So you end up sharing news to others even when it is not published yet. My question today was, ‘is that gossip’?

Looks like there is a thin line between sharing information and gossip. I was relieved to get this definition – Gossip: “casual or unconstrained conversation or reports about other people, typically involving details which are not confirmed as true.” So if the information that one shared is true and it is something that the source(person) is going to release eventually, and sharing it early to a few friends is no harm then I guess it is ok to share, and gather some Klout. But if the person has confided in you and told you not to tell anyone, then you shouldn’t. 🤫

Finish what you start and on time.🕰

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.

  1. Break down the feature into smaller chunks or user stories or work items.
  2. Put ETAs for each of the above items and call out owners.
  3. 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.

Product/Experience fails 🤦‍♀️

I thought I will start a new category called Product fails after two recent experiences with products. When I use this word Product, it is not restricted to a product (furniture, hardware, software), it could also me the experience fails from the time I get to know the product till I experience the product, that includes delivery, post-purchase experience, product experience etc.

For the first post I’d like to start with the recent Airtel experience I had.

For some reason the 4G on my phone was intermittent, I’ll step out of my house and switch on maps, and 4G wont connect and I wont see a 4G icon next to the network icon.

Even when Mobile Data was on, I wont get 4G.

So Imagine my surprise and the bad experience when I want to book an Uber back from a restaurant. So I called the airtel customer care, and they said try removing the sim and insert it into some other phone and check if that receives 4G. The other didn’t. So we figured out that the problem was with the SIM. The customer support executive instructed me to go to any Airtel shop and get a new SIM as a replacement for this SIM

I went to the Airtel shop and this is where it’s weird. The executive manning the shop asked for my ID, which I showed and then began filling a form in his phone for the work. He asked me for an alternate number, I told him I dont have an alternate number and I asked back why he needs it. He said it’s a mandatory field in the form. Apparently an OTP will be sent to this number as a verification step. 🤦‍♂️ I dont see the logic here. If somebody else were trying to get a SIM replacement (and why would they get a replacement), even they can produce any alternate number and get the OTP. Anyways, I told the guy I dont have an alternate number, so he was stumped, ‘sir can you just get some friend’s number’. I realized nothing’s gonna move forward here. So I told him that I will come after sometime when his colleagues come and maybe they could help. Thankfully when I came back, there were two other ‘more experienced’ chaps who got me the new SIM without asking for any OTP. But if it was left to the first guy, I’d still be struggling to get the replacement SIM.