The Customer is Always Right, Right?
Customer collaboration is critical to building successful problems, when approached the right way
I was talking to some peers around challenges they face and what they feel they need to do in order to make progress in their roles.
One topic that came up was that of overuse of meetings by people. One, a Head of Product, has reached a level of seniority where she is now a stakeholder who needs to be aligned, so everyone wants some of her time and her inbox fills with meeting requests that she feels obliged to accept. Another senior product leader talked about an apparent organisational fixation on participant-heavy workshops.
Effective collaboration is a topic I’ll return to another day, but I want to go through what happened during and after our conversation, and what lessons there are for how to approach solving a problem, and by extension product development.
As we were talking we discussed the cost of meetings, and how it is an invisible cost. Does it even occur to people that holding a 3 hour workshop with 10 people will cost your organisation thousands of dollars. And what do you get in return?
If you want to be more accurate, the organisation is really facing an opportunity cost. After all, those people could have spent those three hours talking to customers, or watching cat videos on YouTube, either of which might have been more valuable than the workshop. (I don’t know what the workshop was or who was facilitating it, so both those things might be more valuable).
The conversation hovered briefly around the cost aspect and the belief that most people don’t consider that cost. What if you made it more obvious to them? Wouldn’t it be cool if there was a little warning before you send a meeting invite that says, this meeting is going to cost $6000, are you sure?
The conversation moved on to other things, but a seed had been planted.
From Conversation to Action
A few days later we had a long weekend here in New Zealand. And what do I do on the Saturday night of a long weekend? Well, this time I sat with my laptop and Cursor, and built a little Chrome plugin that will calculate the cost of a meeting in Google Calendar. It took a couple of hours to get something basic that worked, most of the time spent trawling through the Google Calendar DOM. By the way, shout out to the Chrome team for using really clear Aria labels. A11y for the win.
But I didn’t stop there. No, it got me wondering about publishing to the chrome store, which is something I’d never done. So I gave it a go. It’s a pretty straight forward process.
First up you have to register as a developer, which involves providing a bit of information about yourself and paying a $5 fee. Then you are able to submit your extension to the store review process and create a listing. This involves describing the purpose of the extension and the permissions the extension needs to work, your privacy policy, and data you are going to use and so on. The listing needs some description and some images to help people understand what they might get.
A couple of days later, so long as you’ve met the standards, there you have it, your Chrome extension up on the store available for everyone to use. If you are a Google Calendar and Chrome user, you can try it out for yourself, or if it’s more your thing you can get the source code.
From Action to Silence
Before I go any further I want to do two things. First, I want to be clear that my purpose in this exercise was learning - I wanted to see if I could figure out how to make a chrome extension that calculated the cost of a meeting, and then what the publication process was. The second thing is to give you a chance to reflect on how many mistakes I made in terms of launching a product.
If you go onto the chrome store and search “meeting cost”, you’ll find my meeting cost calculator and 12 other extensions that do roughly the same thing. None of them have many ratings, the two most popular extensions have a thousand users, many have fewer than a hundred. What to make of those numbers? Well, let’s give it some context, the Chrome Web Store has extensions concerned with productive meetings listed with millions of installations.
Additionally there are lots and lots of reports and studies on how meetings are on the rise, and have increased since the pandemic. So organisations are spending more time and money on meetings. There is also plenty of research out there that says that an awful lot of time spent in meetings is unproductive.
What’s going on? The “customers” I talked to thought the meeting cost calculator was a great idea. And to make matters worse there are plenty of meeting cost calculators available, but people aren’t using them. But they said they wanted one - why aren’t they using one?
How many mistakes have you counted so far?
I’m going to assume you might have run out of fingers to count them.
The Solution Fixation Honey Trap
The first thing to call out is the problem was a stated preference. Our brief conversation led to everyone saying what a great idea a cost calculator was and wouldn’t it be a great way to make people more mindful about scheduling meetings? The market would suggest otherwise, but I haven’t done enough research to be definitive.
The main mistake I want to highlight was that of premature convergence. To give you my frame of reference for this term, I like the approach of Design Thinking, which is a user-centric approach to problem solving. This approach aims to solve problems based on the needs of people:
Empathise: Understand the needs of the users
Define: State the needs and problems of the users
Ideate: Generate ideas and solutions
Prototype: Create a product to test ideas and changes
Test: Try out the solutions
I effectively got through stages 1, 2 and 3 in about 10 minutes of a conversation. I did not deeply understand the needs of users before really defining the needs. If I were to go through the process properly I would have spent a significantly longer time talking to users, and more than two of them.
The convergence language comes from the double-diamond of the Design Council.
This describes the early stages of discovery being divergent, that is being open to going in different directions. Only once you have thoroughly explored the problem space do you converge on your defined problem to be solved. You should also be open to exploring different options to solving the problem, which is another divergent activity opening up development options to be prioritised and validated before converging on delivering your solution.
Looking back to the start of this process, I quickly grabbed the idea of a meeting cost calculator and followed it through to conclusion before fully understanding the problem, exploring other avenues or validating it.
In this case my objective was primarily learning, and the cost was a few hours of my time and $5 to Google that they didn’t really need, so it’s not a big deal.
But I wonder how much money is spent by organisations who fall in love with solutions too quickly?
How not to product
So this is a lesson in how not to product. Unproductive meetings is objectively a problem worth solving, and something that organisations may well spend money to address.
Now the cost of coding is driving towards zero and the ability to whip up a prototype is available to anyone, the risk of identifying a solution and getting fixated on it is even greater. Solving any problem needs to start with deeply understanding the problem space first.
And talking to customers is essential, but you need to bear in mind the full quote from Harry Selfridge: “The customer is always right, in matters of taste.” Do your best to find out what they actually need rather than what they simply state they want. Validate and iterate your way to a solution and you’ve got a chance of creating something truly useful and valuable.