“The art of communication is the language of leadership.” — James Humes
In retrospect, all my successful projects were the ones where I overcommunicated everything.
There was no room for assumptions and different expectations. Therefore — everybody got exactly what they expected. No ambiguity, no disappointment, no pressure for the team, and a happy client.
Retrospective
There’s a common pattern when success is not the outcome:
- Your client adds “one more thing”, just before you planned to go live, which breaks your solution architecture apart. As a result — refactoring, unstable product, delays, overtime;
- A couple of “edge cases” appear, breaking your happy flow. As a result — more refactoring, pressure, bad coding practices, deadline delays, lower profit margin;
- Requirements are poorly described, leaving room for individual interpretation. As a result — the client’s expectations are not met, gaps in understanding, more delays.
Root Cause
How do we get into these situations?
Usually, the client spends a lot of time thinking about the solution. And then, after a lot of brainstorming, workshops, etc. your client tries to convey the idea within your 1-hour kickoff meeting.
Basically, they are trying to compress the knowledge transfer in an hour, while it took them weeks and weeks to get to some degree of understanding.
In situations like these, your job, as a product manager, is to structure and shape the idea of the product, based on the bits and pieces you just got.
Action Items
How can you shape the product with such a small set of information?
Expand the Knowledge With Your Assumptions
In an ideal world, you would get a product vision board, functional specification, and wireframes from your client.
But in the real world, you’re the one who has to create these documents.
The only way to create them is by taking what you learned during the kickoff meeting and expanding that knowledge with your assumptions. Try to approach this with a beginner's mindset and try to learn and understand the needs of the product that you’re building.
Build Your Beginner's Product Specification
Before you start building the product, build your product specification first.
It’s a beginner's specification since you’re building it based on your limited knowledge and a lot of assumptions. But basically, this should say:
Thank you for sharing the information. Here’s my interpretation of what I’ve learned and how I understood your needs. This specification describes my understanding of the product, and if you have nothing else to add or change, this is the product that you’ll get.
Of course, you’ll communicate this more politely, but that’s the message you want to send to your client. The framework that I love using for this — HAMMER Product Planning Kit.
Validate Your Product Specification
More often than not, clients don’t have enough time to compile a product specification.
But when you build it for them, it’s much easier for them to go over the document and verify all your assumptions and interpretations. They will read through the document and detect the things that you failed to understand correctly (or they communicated it badly).
Also, they will approve what’s good and disapprove of what needs to be changed. Furthermore, this specification will make them think about more edge cases, giving you even more knowledge.
The Art of Communication
Your goal here is to collaborate with your client on your product specification.
By doing this, you’ll get shared accountability — you’re no longer the only one responsible for delivering a product that doesn’t meet the requirements since you both approved the plan.
By building your product specification, you’ll show that you’re proactive and your client will know how to appreciate that. Also, collaboration on the specification will inspire your client to share more knowledge with you. You’ll be able to detect more edge cases upfront, leaving less room for unwanted last-minute refactoring.
You’ll be able to set the right expectations, align your team with the client’s vision, and deliver the right product. Having a clear product specification will lead to a clear roadmap. You will be able to hit every milestone since you put so much effort into planning upfront.
In essence:
- Build the plan based on your assumptions.
- Verify your assumptions with the client.
- Iterate on the plan until all parties are happy with it.
- Create your roadmap based on the specification.
- Communicate the progress and your next steps.
Where to start?
Everything mentioned in this article (and much more) is part of the Notion template that I recently created. The template is already adopted across my organization. It’s extremely useful for new projects, where you have the entire structure laid out, ready for you to start rocking. You can find the template here.
I use this concept for each new project. It helps me understand what needs to be built and why. Having this in writing helps me communicate the product plan with team members and stakeholders. As a result, everybody is aligned, motivated, and contributing to the shared goal.
This template will help you:
- Create your product hypothesis and understand user needs.
- Let your team know what to build and why are they building it.
- Let your clients (investors) know what they are getting.
Good luck! 🍀