webinar, online

Developing the Right Mindset for Product Success

6:00 PM

64 came

With Vignesh Suresh

What happened

Vignesh Suresh grew up around Coimbatore and was speaking from Dublin, where he is a senior product manager at Guidewire. His premise was that the internet is full of courses teaching the hard skills and nearly silent on the rest, and that the hard skills change with the role while the mindset does not. He had seven learnings, each hung on a metaphor, and the metaphors did more work than that usually implies.

The first was about the two opposite ways of getting customers wrong. Some product managers learn a domain well and then quietly drift away from the people in it, so their understanding stays fixed while the customers' problems move. Others stay so close that they start taking solutions from customers rather than problems. His line was that the customer is the best source of a problem statement and a poor source of a solution.

The one people wrote down was "serve water first, fuse later": give the exhausted person a glass of water before you offer them anything clever. He paired Trello, which stayed deliberately simple and solved the problem it had, against Clippy, which he called the forefather of the chatbot and which interrupted people who were trying to work.

The rest ran in pairs, one that worked against one that did not. Amazon Prime bridged retail, media and convenience; Juicero sold an expensive machine and proprietary packs and bridged nothing. AirPods fitted their pieces together; Google Glass had innovation without a use case anyone wanted. Adobe harmonised a suite; Yahoo never made its services into one thing. Google has kept the marathon going since search launched; BlackBerry had the best security in the market and stopped noticing that user needs had moved. He quoted Bezos on Amazon failing one day, and the job being to delay it.

The most practical part came out of the questions, on the problem every enterprise product manager has: the roadmap is set and a tier one customer wants something that will take four sprints. He scores each candidate on impact, effort, the company's own standing priorities, and who is asking, with larger customers weighted higher, then adds them up. He was candid that this is something he is still experimenting with, and that the point is to avoid both failure modes: saying no to every large customer, and rearranging the roadmap whenever a big one asks.

He also gave the tell for a bad problem. If you cannot get twenty minutes of a customer's time to talk about what you are building, the difficulty is usually not their calendar. It is that you are solving something they do not need solved, and the right response is to go back to the ideation board rather than to send another invitation.