MVPs always seem easy to execute and build. The first version is shipped with a few features and development is simple to manage.
This simplicity affords a focus that is disciplined and strong, because those initial features stand for the core idea.
However, as an idea grows, so do its changing product priorities and ever increasing customer feedback demanding change. What was once a simple product vision can become something verbose which can easily lose sight of what made it mean something to people in its infancy.
The Problem
Technology companies typically have either a top-down or bottom-up approach to product development.
A top-down focus usually means that leadership directs all product decisions. A bottom-up focus is driven entirely by research and feedback.
Beauty lies somewhere in between, when these two approaches are taken together.
However, when one weighs in more problems start to occur.
TOP DOWN FOCUS
Characteristics of a top-down approach to product development look like this:
- Investors tell leadership what to tell the product teams to build
- Investors and leadership hold meetings where they make decisions about the product without a lead product team member present
- Leadership gives the product team a list of features they want to be built
- Leadership changes sprints mid-way through because they want something added or changed immediately
- Leadership plan sprints and direct the product roadmap, whereas the product team simply executes with no involvement in those decisions
BOTTOM UP FOCUS
On the other side, a bottom-up approach usually looks like this:
- Leadership stay out of product development in general and focus on setting business priorities in the form of objectives, KPIs, and strategy
- Leadership have frequent meetings about the direction of the product with suggestions in hand but accept push back from product leads
- Leadership makes suggestions but the product team leads always have the final call
- Leadership avoids and rarely engages with worker-bees in the product team (designers, developers, and so on)
Any of this sound familiar?
These characteristics can paint a picture of any product development environment at a startup past seed stage.
So what is the problem with all of this and how does this lead to malformed product visions?
It comes down to communication.
The communication of ideas about how to make the product better while keeping it in line with the original vision.
People don’t like confrontation. Depending on how top-down or bottom-up the environment is impacts the degree of how much honesty people display to others about ideas and suggestions.
This is because people don’t like to know that their ideas and suggestions aren’t very good … and people don’t like to tell people that their ideas and suggestions aren’t very good.
No confrontation, no drama, no drama, no anxiety about my job.
When this honesty isn’t enforced and managed it takes the product vision on a rollercoaster ride of changes.
The needle in the haystack is that these changes are sometimes hard to spot in the beginning and they seem like good decisions but can result in disasters over the long term.
Solution
PRODUCT THEMES
Product themes are the gatekeepers that are summoned to protect the team’s focus and make communication between people more honest.
Product themes sit at the table when people are talking and making decisions about the product.
You can think of themes like the secret service or the armed guard. They have sworn an oath to protect the team’s focus from being hurt, lost, or altered in any way.
Instagram used themes and we can all agree that they’ve done well to keep their product vision under control.
“In the early days of Instagram, Krieger and his team recorded their action items in a rolling Google Doc, organized by themes.” — Source
Product themes act as a negotiator between people because they interject and help facilitate people’s ideas about or related to product development.
“One of our themes was being the fastest photo-sharing app in the world. What are we working toward within that theme? Next, we wanted to make the photos look incredible, way beyond what you’d expect from a cell phone. What are we doing on that? Anything that didn’t fit into those things went by the wayside. “ — Mike Krieger, Instagram
“Anything that didn’t fit into those things went by the wayside” — this is the important part.
Instagram used themes to keep their focus in check.
It would have been easy for the Instagram team to hold a meeting and accept suggestions from any direction. But these suggestions could have taken them away from the focus of “becoming the fastest photo sharing app in the world” if that theme wasn’t defined clearly before.
This is because communication generally has the most impact on focus during meetings.** People easily impart views based on assumptions that can lead their focus astray or down another path.**
Imagine if Instagram did not have that theme at the core of what they were building, and instead took suggestions as they went along (like in an Agile environment).
What if they looked at what people wanted at the time — adding more granular photo editing tools — and tried to implement that? Perhaps Instagram would have been closer to what Adobe Photoshop is.
But instead, their product themes protected this from happening. They ensured that the communication between team members was kept on track. And people didn’t have to feel like they were being swept aside or not valued by their team. It wasn’t Mike who said an idea wasn’t good. He used the themes to justify his opinions, so there was little confrontation.
Essentially, product themes give people permission to tell any team member that what they are saying is distracting the team from the core focus.
Where do themes come from?
Product themes come from the creators beliefs about life or the problem they are trying to solve.
Themes have depth and are often rooted in strong beliefs about what should be true about a product or its impact on the world.
A theme is a big idea, and it usually touches on human experiences that everyone can relate to (so they are not technical descriptions).
HOW THEY WORK
To create a product theme, you must come up with a set of statements that embody strong beliefs and convictions about the product itself.
Instagram’s main theme was: “to be the fastest photo sharing app in the world.”
This is strong assertion and a clear message that has depth. People looking at Instagram today and would probably say that it embodies that theme.
Instagram’s users support and drive that theme when using it without even thinking it about it — the theme is in the product’s DNA.
When a team is having discussions, planning the execution of the product, this theme must be present and “at the table” with them every day. While the theme is present, it permits the team to discuss only ideas and information that make that theme become a reality.
I guess you could think of a theme as spirit that wants to live in the real world.
It wants you to make it real and protect it from being anything other than what it wants to be.
This is why I believe product themes can be a simple framework that protects the team’s focus and makes the way we build products more inclusive and effective.
HOW TO USE THEM
In order to take a structured approach when using product themes, you must first adopt the mindset of Shipping VS Learning. In this mindset, teams prioritize learning as a regular deliverable over shipping stuff. This is the underlying method that guides how product themes can be used to drive product decisions.
Here are some things that can go wrong when teams ship stuff without product themes guiding them:
- Teams ship inferior or non-impactful products in order to say they shipped something
- Teams ship things that teach their company nothing
- Teams aren’t given enough runway to do great work because of the constant pressure to ship ASAP
On the other hand, learning as quickly as possible and making sure that learning is prioritized is the most likely contribution to product success. Shipping is part of the learning process, but learning comes first.
A SPRINT TEMPLATE
Here is what a theme-based sprint could look like over the course of 2 weeks:
- Product theme: make achieving any career change the easiest journey possible
- What we learned: Removing steps from our onboarding experience did not reduce user confusion. Instead, clearing up language such that users felt they were making progress resulted in the greatest gains (link to more details here).
- Cost to learn: One researcher, one designer, and one week of their calendar time cost €200 in user participant fees.
- Plan to proceed: Productionize new language within one month.
- What’s needed to proceed: Some internationalization help… we’ll outsource this.
According to Shipping vs. Learning, What we learned is the key deliverable, and it’s something potentially interesting to many people across the company.
Cost to learn is a chance to optimise for and highlight efficiency, as spending a year of engineering time carries much greater opportunity costs than running some efficient, qualitative testing.
Plan to proceed lets people know the outcome of the learning and how it affects the way forward.
And finally, what’s needed to proceed spells out what a manager, executive, or anyone outside the core team can do to help.
It can be very easy to spend weeks and weeks shipping product then learn absolutely nothing about how the product theme is going to be realized. This is why it’s so important to learn and spend time rethinking how people within the team approach learning and contributing to how product themes.
Sprints should be organised by each of the product themes, where tasks follow whatever system you are already using. Incomplete tasks under each theme can be pushed along to another sprint, but the identity and purpose of every sprint is never lost.
It isn’t about what are we shipping this week. It should become what can we learn this week to realise the product theme better than we did last week.
Wrapping up
In conclusion, when building a product it is imperative that a narrative is made around what the core themes are and how your team prioritises development efforts around them. Everyone within an organisation should be made aware of what the product themes are so that everyone has the opportunity to manage the overall development towards realising them.
Product themes are not an afterthought or something related only to the product’s department. They should be respected and managed just like a company vision or mission statement. I would even suggest that, in some cases, product themes are the foundation to a long lasting company statement of purpose.