👋 Hey there, this is one of the less focused posts where you get something I hope you find interesting. If that sounds interesting, or you’re interested in the more serious one about product management, tech, or climate change sign up😊.

The problem with experts is they always start from the exception. They have lots of knowledge about their domain, they see it from a birds eye view, and they’ll tell you the most interesting, useful stuff. As they should, they’re the experts. But if you’re asking for input on something, to learn about what they’re doing, or about what’s interesting in their field, good luck getting something actually useful. I learnt this the hard way.

Story time

At the end of last year I was helping develop software for ‘Environmental Impact Assessment’ consultants. A tool that would help them do greenhouse gas (GHG) accounting better and more efficiently. I started by asking questions to better understand their problems, I spoke to seven in-detail, I mapped out their processes, wrote out the obvious issues and user stories, and had them validate my findings.

From there we made the plan, and validated as we went. We took at least an hour each week with all of the initial users in attendance so I could present the plan, the priorities, and the progress.

Most of the time during these presentations someone would point something out that was off, or could be easier, or that I’d missed. Most of the time we’d have discussions about the details of the plan and end up making improvements. I was getting a lot out of the calls and they continue to this day.

Time marched on, we hired another Product Manager (the wonderful Andreas Svennefjord) to take over this project from me, and the MVP was built.

On paper, the MVP was solid. It had (almost) all of the things we agreed it would have and more importantly, the consultants could use it for its intended purpose. We had created a working MVP. Go us 🎉

Time continued to march and more people joined the team, a new head of UI/UX, and more developers. So we had more bandwidth to work on more stuff and do more things. Then, one fateful day our wonderful designer got on a call to shadow one of the consultants in their day to day workflow. A step I had not done originally because of time constraints (I will not make this mistake again).

She let me know later that she had learnt a myriad of things. I thought that was great, I wonder how much is new vs what I learnt on the first go around. The fundamentals were there, the workflow, the concepts. But how those things were conducted were skewed. The way things were laid out, the data we presented to the user, and how they interacted with it could all have been improved.

I’ll be honest, I was a little embarrassed, how had I missed all of that? I asked Andreas and he said the same, that when he asked the consultants for feedback on specific things they gave a similar response. They would give small, but numerous, corrections. I didn’t understand.

The same day I had a call with a couple of consultants trying to use the tool for something massive. Just huge. (honestly, too huge, it’s a mess that started before I joined and I’ve been trying to get out of since). It’s entirely not what it was built to handle. I showed them the interface, asked them what they thought, and they started talking about how they could make it work with relative ease for their use case. And it clicked.

When I was doing the research initially the experts were telling me and feeding back what would be useful for their particular cases. For their special, difficult projects, that they would like us to automate. The result was fundamentally correct but a mix of bits and bobs that tried to address problems that we hadn’t scoped for.

I should have caught this. It’s a complex thing that they do with relative ease. They’re not used to writing user stories, I should have explained to them, and I shouldn’t expect the user to do my job for me. As a user they should present the problem, bring me what they have, and help me internalise and understand it, I’ll handle the solution and validate it. Instead, I seemed to have taken bits of their solutions and bent them to fit into ours.

Of course, without that first version, without that MVP, we wouldn’t have discovered any of these things and then some. Now that we have a working first version, we can iterate, we can improve, and we can kick some ass. Plus, it gave me something to write about and reflect on.

Lesson learnt

Is it a problem with experts or my own problem? It’s my problem. I’ll do it better next time. Experts start from the exception so you have to guide them to help you understand the core problem. Whether that means shadowing their actual work flow, or helping them to get to the bottom of the actual problem they’re facing.

For example, if the goal is to make poached eggs and I ask you how I can help, if you’re an ‘expert’ you might say I need help putting the eggs in the pot. I might assume from that that the problem is you’re doing it by hand, so I bring you a slotted spoon. But maybe the problem goes deeper than that. If you’re an expert you’re thinking of the exception. If I were to shadow your poached egg process I might find out that you’re in fact using a frying pan and partial boiling to poach your eggs (like a maniac). In which case a slotted spoon isn’t the best solution, but tongs are!

Thanks for reading. The best way to support this newsletter is to sign up ✍️ share it 🤝 and get your friends to sign up too 😎 That’s what this lovely purple button is for 👀