Dissecting a well structured and effective Product Proposal
Being honest straight away, I’ve only done digital product at one company. As such, I’ve only been taught to run a well structured product proposal in one manner. Without any prior experience in the field, my superiors at the time introduced me to the below structure (so, credit to them). It stuck. Why? The structure has proven time over time again to be a powerful way to think about, prepare and present a proposal.
Not only that, it’s an efficient and practical tool before the proposal even reaches the state of being a proposal. As you’ll see in a minute, there’s no point in spending time on a proposal if it’s not going to bring added value to the table. Or if its targets are not in line with the company’s strategy and/or targets. Every question you ask yourself before making a proposal ultimately boils down to the same reflection point. How impactful is the end result going to be?
Asking yourself this question is in essence step zero of the workflow that encompasses all other steps at once. As soon as you have determined that the core of the proposal will have a significant enough impact, the funnel below becomes child’s play.
Let’s get to it.
1. Problem / Opportunity
It’s important to understand that a product proposal is nothing more than a result of one or more opinions. Before all else, if it’s your opinion, there’s a huge pitfall to easily overstate the possible impact and importance of it.
Thinking about the problem and the helping hand it should provide, will make it easier to be critical about your own opinion. How is your opinion going to help the users, the customers? Citing Facebook’s VP of Product, Julie Zhuo:
“.. have an opinion about which problems are worth solving and convincing other people of that.”
The word ‘solve’ is super important here, cause it’s the first and most legitimate part of the product proposal. What problem(s) do we want to solve with this proposal? Instagram recently changed the ordering of users’ feeds from time based to importance based. The reason will not have been ‘just because’ or ‘just to annoy users’. When they first announced the change on their blog, the first paragraph immediately mentions the problem(s) they’re trying to tackle.
“As Instagram has grown, it’s become harder to keep up with all the photos and videos people share. This means you often don’t see the posts you might care about the most.”
Instagram’s product team’s opinions will always have started from this core problem. I’m 100% sure that if at any point the people involved for the proposal got stuck in the creative process, they’ll have used this problem definition as first buoy.
That being said, certain proposals can also grow from a feeling of opportunity. Linked to the above problem, Instagram’s product team will have asked themselves: what opportunities are we missing out on?
It’s not an easy exercise as it’s very easy to just answer with the core idea of the proposal. The opportunity for Instagram is not to show more posts you care about. That’s the solution. Opportunities should be grander in scope and thinking about the bigger picture. For Instagram (I’m just guessing here), the opportunity could have been to increase retention and user satisfaction of both the viewer and the poster.
The defined problems are preferably backed up with some kind of ‘evidence’. Analytics need to support the problem definition otherwise your problem might be less of a problem than you might have thought. Or even false.
Being a product designer makes you perceive certain aspects differently. Alas, only a few people and probably even fewer users of your product, think like you do. You might think that something is a very big problem, but the analysis might prove that in the real world, it shouldn’t be prioritized at all.
The analytics are mostly measurable in some manner. A few analytical questions that can be asked are:
- How many users are affected?
- What type of users are affected?
- Do we have survey/user data supporting the problem definition in this proposal?
Look at your product like a vase. A very small crack is way more important to fix than a big spot where the color is starting to wear off. Users might agree that the worn off color isn’t super pretty, but it does its job. The crack is something where users struggle. And it might grow bigger or eventually break the vase. The analysis will show you that the crack is already withholding your users to properly interact with your product.
Tinder’s product guy Scott Hurff uses a very useful tool to spot these ‘cracks’. It’s called the Pain Matrix. You go out and try to discover all the pains your users or potential future users have. Some pains will have a high level of frustration, some will be rare and unique. Scott mostly pitches it as a tool to determine the need for a brand new product. But it’s equally useful for an iteration of a product or a new product feature. In a world where your product already exists, everything in the top right part is basically a crack in the vase that needs fixing.
How are competitors solving the problem? Or not solving the problem? Maybe they’re avoiding the problem, which is also a kind of solution.
Don’t limit yourself looking only at your direct competing neighbours. Inspiration is all around us, especially on the internet. Don’t be afraid exploring and investigating different types of industries, even if they’re night and day from your type of business.
Don’t limit yourself looking only at your direct competing neighbours. […] Don’t be afraid exploring and investigating different types of industries […]
A good competitors’ analysis is important not only to feed you ideas and brainstorm even more opinions, but primarily to, once again, support your problem definition or opportunities.
Analyzing the competitive market brings a great deal of fear. Is it tainting my own ideas or opinions? Am I going to solve it in the exact same way now that I’ve seen one or multiple solutions? Stop. Realise that you’re basically walking the same shared pathway.
Instagram’s ‘importance over recency’ feed can be found in tons of other products. The core idea isn’t ground-breaking or unique. The elaboration of the core idea is where the value’s at. And if you already had a better core solution in mind before you checked out your peers and competitors, you’re going to stick with that original idea either way.
This is the meat of the proposal, since it’s in fact eeuh.. the proposal. :) The core question for the proposal part is pretty obvious: how are we going to solve the problem?
The answer to that question can take many forms. Drawings, wireframes, mock-ups, basic logic, heck, even a full-fledged prototype. This article isn’t really about how to design a product or about the process of creating good UI and UX. There are plenty of other sources about that. Let’s just go over some important basics that every good product manager/designer should be aware of.
Mobile first! There might be some rare exceptions, but in this day and age every proposal should be figured out on the smallest viewport possible and work your way up after that. Having less space to work with let’s you really think about what’s crucial to present and what’s optional. Do this now if you’re not already doing this.
UI Stack! A screen never lives on its own. When working on a proposal, it’s easy to just think about that perfect flow and go from there. Your idea might get approved and even reach the engineering phase. Everything looks great, everybody’s happy. Don’t get fooled by this. Problems will occur if you didn’t account for all UI states for every single screen. If the product goes live without having considered the UI stack, you’ll create very awkward UI. There are five states: blank (i.e. no data), loading, partial (i.e. some data, but not all), error and of course ideal. Scott explains in detail what each individual state represents more elaborately here.
Copy! I can’t stress hard enough the importance of well-written copy. A good product designer shouldn’t have to rely on copywriters. Your product is dealing with people. Let the product treat them as such. John Moore Williams has written plenty interesting and useful articles about how a product (or UI) designer should focus on copy. He explains why content comes first and has a nice list of ten tips on writing good UX copy.
These are the three core proposal elements I wanted to highlight. As said, there are plenty other key topics when working on product UI. But if you nail mobile, the five UI states and the copy, you’re more than half-way to a very good solution to the problem definition.
Since your analysis supported the problem with quantifiable metrics, the follow-up on these is at least as important. It’s key to know exactly how your product is going to be used. What aspects need to be tracked in the proposal?
It’s impossible to evaluate the success of your idea/product when you don’t have the data at hand. So prevent this problem by clearly defining what needs to be tracked. If you’re fortunate enough to be able to work with a team of data scientists, discuss the tracking as much as possible with them. They’re the experts after all. Make time to explain the core idea of proposal, so they have a good insight as to why certain metrics are important to track.
Personally, I find this the hardest part of a proposal. Targets are a key part of the proposal so don’t try to get off easy when setting your targets. Ultimately it comes down to two parts:
- Which metrics are part of the target? A new launch screen or sign up flow will most likely have targets related to the registration funnel and less about activity. Choose target metrics that make sense for the proposal.
- Estimate what a realistic target is for the defined target metrics. Don’t under or overestimate. It’s not easy. Your proposal will be evaluated against the targets that you defined, so don’t tread lightly about this. The golden rule that helps me set up an achievable but at same time ambitious target is: at which point do I personally and my superiors think that the proposal has been a success?
The target metrics should be more or less based on the analytics obtained previously, since we’re trying to solve that specific problem. Having good targets is super important to know how the proposal will be evaluated.
Targets set need to be specific, measurable, relevant to the proposal and need to be set in time. Increasing female retention by 5% is not a useful target if you don’t know by which point in the product’s lifecycle you want to achieve this.
7. Planning & Resources
The last part of the proposal is pretty straightforward. Since every proposal is trying to solve a problem, it’s recommended to give it a place between all other problem solving proposals that made the cut. Here at Twoo, we used to do this more strictly, with two scales reaching from 1 to 10, being:
- What is the level of urgency?
- What is the level of importance?
We don’t explicitly define these anymore for proposals, but they are still implicitly conveyed when the proposal is being presented. The two questions above don’t give the full picture though when it comes down to the overall impact on resources. You should always keep in mind what the resources required are for the proposal. Both for the product team and the development team. A problem can be solved in many ways, it’s probably best not to go for the solution that takes up multiple weeks of a whole team if another solution just needs few man days.
Meticulously and passionately working out each of these seven steps, will result in a well structured product proposal that has all of its bases covered. It’s crucial to have the information of all of these steps available to all layers of the company, from development to marketing to upper-management.
If everybody knows why something is a problem, how we’re going to fix it and what we want to achieve, the end-result will always flourish.
- See The Moments You Care About First, Instagram Blog, March 15th 2016
- Quora Sessions with Julie Zhuo, Julie Zhuo via Quora, April 1st 2016
- How Do You Decide What To Build, Scott Hurff via Invision Blog, November 25th 2015
- How To Fix a Bad User Interface, Scott Hurff, 2016
- 10 UX Copywriting Tips For Designers, John Moore Williams via Invision Blog
- Why Content Comes First, John Moore Williams via Invision Blog
- Internal Product Proposal Template @ Massive Media Match NV