You recently started owning a feature in a product. The feature and set of underlying services are several years old. Some aspects are showing signs of aging; there’s some amount of technical debt around. Architectural assumptions are probably a decade old.

How do you set out in the journey to make the product better, modernize it and fix the architecture? Where to start? Let’s bounce off a few ideas on customer aspect in this post and talk about architecture in another post.

A key takeaway of the ownership transition is ability to take decisions. Decisions can range from simple triage of product features or bugs to deciding product direction. E.g. which scenarios are higher in priority? Which scenarios are way behind the market? Where should we invest our resources?

End of the day - we should be in a position to get in shoes of the customers and be their representatives in the product team; influence the engineering decisions based on our conviction of requirements.

Ability to take decisions = f(customer understanding).

Where to start?

How do we even begin understanding the customers?

The engineer quickly answers lets look at the telemetry. Telemetry is what people do with tools available. It doesn’t represent what doesn’t exist. I’ve a lot of respect for data science and allied disciplines, but telemetry or data crunching is at the best a complementary tool to talking to customers. Not good.

If I start talking to customers for a decade old product, I’m afraid every word customers are going to utter will be a about a bug in the system. So be it. It just means that we have lost the trust and need to gain it back. You can argue that the outcome of customer discussion will not be definitive. It will be a waste of time.

I looked around the interwebs to find an answer to this.

I came across a nice set of articles by Steve Blank↗ on understanding customers, scenarios and requirements. He calls this process Customer Discovery. Looking around I realized my ignorance :) And this idea of customer development stems from a great book The Four Steps to the Epiphany. Guess what, the book has been in my reading list since 8th April,2011. I know whom to blame!

Read about Steve’s point of view here: https://www.slideshare.net/sblank/customer-discovery-23251533↗

Please read it through. And a nice set of videos are [here][customerdis]. [customerdis]: https://startupweekend.wistia.com/projects/zt618zz0r7↗

Going back to the waste of time and subjective outcomes argument, the Customer Development model provides a nice toolkit for conducting customer interviews and understanding opportunities. It appears to be a protocol, not entirely a piece of art.

Next question - we are a big organization, our product already exists. Customers have provided feedback in User Voice. Why not just do what they say?

Let me quote [Cindy Alvarez][cindy] from [this article][pm]: [cindy]: https://www.cindyalvarez.com/↗ [pm]: https://www.cindyalvarez.com/how-do-customer-development-and-product-management-fit-together-2014/↗

In traditional product organizations these opportunities usually come through VOC (voice of the customer) feedback. But customers are often unable to articulate what they need, especially if it’s something they don’t even realize is a problem.

The active “pull” of customer development interviews, as opposed to the passive “push” of VOC, gets richer feedback (and guarantees that you aren’t being unduly influenced by your “squeaky wheel” customers.

I’ve done the mistake of just doing what is mentioned in User Voice. That one ask had ~3000 odd votes, was the top most ask. It was filed in ~2012 and we got to it in ~2015. Guess what, people had stopped caring for the issue in that three years. Huge waste of effort.

I’ve also committed the mistake of listening to what engineers say about product direction. Amazing team, great engineering assets, beautiful process and code. 12 customers. Never shipped a v1.0. Mega failure. And this was just before the previous one in ~2012-13.

Before you ask, no, I was not the only entity common in both failures :P

We have to get out and talk to customers. There is no other alternative.

As an engineer

If you’re reading till this and you’re an engineer like me, you may be wondering this 85 year old dude is talking PMish today. Well, partly yes ;) Since I’m just an engineer like you, here is the one thing I’m contemplating to do for understanding customers.

Be the escalation guy in the team.

Let me handle all customer escalations for a month. For every issue I deal with, let me understand how customers ended up in a bad situation. Is the product unintuitive? Are there certain assumptions the product makes about them which are not true any more? What were they trying to achieve?

Alright, the second thing is to learn about the Customer Development process and spread awareness in the team.

Wish me luck.