Using value propositions to improve your product development process
As a content person in a product team I’m often asked how I spend my time, considering there isn’t much copy to write.
To which I reply: I’m a designer, I just design with words instead of pixels!
On a product team it’s my job to make sure that users understand what the product is, whether they should use it and how they can do so. Depending on the project this could involve anything from writing documentation to picking the product’s name.
As well as working on products themselves, product content people also play an important role within teams by helping them explain why they’re working on their chosen problem and how they plan to solve it.
An example of how we do this is by helping them agree and articulate what they’re doing through a value proposition statement.
So, what exactly is a value proposition statement?
It’s simply a single sentence that justifies why your product should exist. If you think of user needs as a problem to solve, a value proposition is the team’s initial answer.
In many projects time gets wasted on false starts and misunderstandings. A value proposition can help teams work more efficiently by ensuring decisions are based on a shared understanding that’s been communicated to their stakeholders.
When I started helping the Performance Platform team at GDS team in June 2016 they were just completing their rediscovery research and had highlighted a new set of user needs for a persona called Anna, the strategist.
These new user needs plus changes in the team meant it was more important than ever that everyone could clearly answer the question “What are we doing and why?”
To start answering this question I organised a workshop based on Sara Wachter-Boettcher’s Content Mad Libs game where teams are asked to come up with statements about the goals of their content in a structured format that can then be easily combined.
Instead of focussing on our content strategy, I asked the team to spend 15 minutes as individuals writing cards explaining what they thought we were doing and what we should be doing using the structure “We help ______________ to ______________ so ______________”.
The great thing about writing the cards in this format is it makes it really easy to see where the team doesn’t agree. It’s also remarkably similar to how you write user needs.
Focussing on what the team thinks it should be doing as well as what it’s actually doing helps surface the hidden assumptions and motivations that must be resolved before everyone can be confident they’ve agreed on the same thing.
All-in-all the team identified 25 different ideas of what they thought they should be doing. Here are just a few examples:
- We help government leaders to make data-based decisions so resources are concentrated on the right things
- We help the public to see data about services so they can hold government accountable
- We help service teams to identify best practice so they can improve their service
I then asked the team to number their cards in priority order before grouping them into themes. Over several iterations we condensed down to 3 main themes (plus a few stragglers) of prioritising work, learning from each other and demonstrating value that neatly matched the high level user needs highlighted in the team’s user research findings.
From these 3 key themes I was able to write 3 corresponding statements that reflected the essential goals of the Performance Platform and put them in a hierarchy based on the team’s priority scores:
- We help senior decision makers to prioritise work so resources are spent on the things that have the most impact
- We help senior decision makers and service teams to demonstrate value so they can get the resources they need
- We help service teams to find services that meet related needs or use similar techniques so they can learn from existing work
Once we had these statements I was able to start constructing the overarching value proposition.
Like most writers I freeze with fear if I even get the sense that someone’s looking over my shoulder but for this final step I decided to write it live on a big screen with the whole team present so they could provide feedback and influence the different iterations.
Although scary, I found the process incredibly rewarding and it really helped in making sure everyone on the team agreed with the final value proposition that:
Performance Platform gives government the data to make better decisions about services.
I then printed it out on a couple of posters and stuck it up around the team’s seating area to provide them with a constant reminder of their shared goal and an instant response to questions about what they’re doing and why.
But that’s not the end.
A good value proposition is a living thing — it’s updated and revisited as the team learns more about how best to meet user needs. For that reason I’ll be holding another value proposition workshop with the team soon to see what new hypotheses have sprung up and how they can integrated into the team’s mission.
