#008: The Messaging Architecture
Ensure everyone knows why, what and for whom they are building.
Part of product discovery is to nail down the user persona and related pain points (see this post for details: #007: Product Discovery and Definition).
This aspect may just sound like one of many TODOs on a PM’s list but it is so fundamental that if not done right all subsequent steps might be impacted in a negative way or may even become useless.
Your product’s user personas and their pain points define the product narrative;
i.e. the essential element to explain to everyone in your org why, what and for whom you are building a product.
It is necessary for
engineers and designers to understand who will interact with - and use - what you are building; it helps them to develop a user empathy and guides them through the day-to-day decisions they may need to take while implementing frontend, UX, backend, admin-panels, dashboards, flows, etc;
the marketers and communication teams to understand how to create the messaging, positioning and branding of the product both for internal and external marketing;
the support team to ensure a compelling customer experience when communicating with users;
the legal team to define the context of compliance requirements;
the communication with potential partners who provide third-party services that must be integrated into your flow, tech or marketing stack;
the management to put business metrics, KPIs, OKRs and business cases in perspective and provide context;
stakeholders in general: to provide an overview and be able to articulate clearly while communicating prior to executing whatsoever.
A simple but effective framework to create a concise overview of your personas and the problem you are solving is what Tony Fadell calls the messaging architecture (see schema in the header image of this post).
It consists of two columns:
“Why I Want It“: explains the reasons why the product should exist.
“Why I Need It“: explains the reasons why the product will be bought.
The columns are filled with personas and simple, clear and precise statements that everyone can understand.
I’ll illustrate the concept with the product example that I had already mentioned here:
Imagine a translation app that allows you to have real-time conversations in any language with anybody.
This hypothetical product experience consists in using a mobile app and an ear-plug as illustrated below:
Let’s call the product “Audio AI“.
A possible messaging architecture may look as follows:
It is important to describe the personas from the “I“-perspective.
PMs and product teams should take time to think and debate until agreement and clarity is reached about the messaging architecture.
Once you’ve nailed it you will get clarity about how to prioritize what to build and for whom as well as how to craft the marketing of the product such as the customer journey, value proposition and positioning.
The magic of the exercise lies in the following observation:
If you think you don’t need the messaging architecture because its a triviality in your product context, I recommend to go ahead and draft it nevertheless as it should not take you more than 15 minutes (since it is a triviality).
If you think it is a non-trivial excercise then more than ever I recommend to work on it.
In both cases, if it takes you more than 15 minutes to establish it, I guarantee you, you will get tremendous added value out of this exercise that will make your future life as a PM much easier.
What are you waiting for?
If you’d like to learn more, there are 3 ways I can help you:
Subscribe to this newsletter if you want to get actionable tips on software product management.
Email me at email@example.com to provide suggestions about blog topics.
Follow or connect with me on LinkedIn here.
Thanks for reading Guide to Product Management! Subscribe for free to receive new posts and support my work.