You Can’t Know Everything
One of the first mini-products that I had to Product Manage was for a client who needed a way to manage rescheduling their installer dispatches. It was exhilarating. I identified the problems and the deeper reasons why these were even considered problems. The team and I spent several hours coming up with and designing a solution. The final output is a system that, albeit complex in technical terms, answers the basest needs of the customer. I was so proud of it that apart from the well executed demo I gave, I also sent out a press-release flyer that summarised what has changed, why we changed it that way, and the outcome we hope it will achieve.
In the demo, I made sure that they understood that this is just the first iteration and something that we’ll definitely keep improving as we learn more about how they use it. The client was pumped. They had nothing but good things to say about what we did and how we’re presenting it to them. They felt confident. We launched it way before people thought we’d be able to. Nailed it!
And then came the emails. “This is not working.”
“All my reports are now messed up.”
“This is just not how we do things around here!”
WHAT just happened?? I was crushed. I didn’t understand where all of these perceived issues were coming from. I did everything by the good ol’ book of Product Management principles:
- Understand what the customer is not getting from the current system. Why do they “need” it, what are they trying to achieve ultimately?
- Prioritise which problems to solve and prioritise ruthlessly.
- Brainstorm with the dev and UX team about how best we can deliver that outcome to the customer.
- Create a prototype quickly and show it to the customer. Gauge whether it is indeed solving their problem.
- If they like the prototype, begin building. Practice lean development to ship it as fast as possible in order to improve on it as soon as possible.
- Demo the final, working design to the customer. The first iteration; the MVP.
- Get sign-off and launch. Learn from their usage and improve on it iteratively.
After despairing for a while and doubting my career choice, I dusted myself off and got to work. Time to find out again what my client was not getting from our solution. It took a few meetings to sort out the misunderstandings, training them on how to look at the data now that the new system is in place and cleaning up their reports for them. In the end, we didn’t need to revise a single component. Our design was indeed providing the client what they needed, they just needed reassurance because hey, change is hard to navigate.
I admit, in the heat of the first feedback meeting post-launch, with everyone piling onto the list of faults and finally, someone raising their voice at me about this crap product, I gave in. I shut down the meeting with a quick “OK! We’ll roll everything back. I’ll let you know when that’s done,” before quickly clicking the end-call button. Head hung, dejected and embarrassed, I confessed to my teammates what I had done and apologised for all the wasted effort. I am just so fortunate that I’m surrounded by a brilliant team including a dev lead who told me No, “can we not do that? Our product works.” It shook me from my stupor and pushed me to take the next steps.
I needed reminder that I can’t know everything. I didn’t know that after shipping the product, there were existing critical reports that would start going haywire; I was never told and I didn’t know to ask. Even after all the precaution I did — plenty of interviews to identify the problems, a prototype, a demo, comms about the changes, a sign-off from the stakeholders— there were still complaints about how the product was not fit for purpose. And that’s okay. It happens and will happen because I can’t know everything all at once! The beauty of lean development and good product management is that we didn’t take too long to try and make everything perfect only to fall flat on our faces. We shipped as soon as we know we have addressed the core problem, learned what else we missed almost instantly, and made improvements after understanding the issues.
Without realising it at that time, I was adhering to the build-measure-learn-hypothesize loop. After building, I measured the outcome by requesting for feedback from the client. I learned what wasn’t working, and hypothesized what would fix it before implementing and measuring their response again.
This role requires you to check your ego at the door. You can’t know everything but a product-led organisation will allow you to learn and discover the unknowns. It’s a humbling job, but the rewards are worth it.
