A humble guide to discussing product with your team

Why you should involve your whole company using google docs.

Peter Kadlot

Published in

UX Collective

7 min readJan 4, 2019

There’s a secret to every successful startup. The people working there think about the product all the time.

All of them. This includes not just the managers, developers and designers, but every single department: customer support, sales, operations, etc.

On an average day, a member of your customer support team will solve hundreds of tickets, building a much better picture about what’s important to your customers than you can by just drawing strategy diagrams on a whiteboard, looking at analytics charts or rewriting your frontend with another javascript framework.

Here’s the problem though:

Nobody listens to them. There is a big disconnect in every large company between the teams that define the product, the teams that build the product and the people who actually use the product every day.

We certainly faced this problem: Every time someone faced a problem they just worked around it and told nobody or even worse, if they did, it quickly got lost because it was not compatible with how everyone else were planning the roadmap.

Easy, just ask everyone what they want!

Not so fast!

Although we were already using memos to discuss ideas within the product team, when we opened it up for the bigger company, it didn’t go as smoothly as we thought.

The problem was, most people were hired to talk to customers, make sales, plan content etc. and coming up with improvements was simply not something they thought as part of their job or were necessary good at.

We need a way to capture their ideas in a way that’s compatible with the way we work.

To help them we made a template for starting asynchronous discussions around new product features: a list of questions and a guide on how to answer them. It was sort of like a bug report, but for new features requests. We called them proposals for change, but it can go under many different names like briefs, RFC-s, feature requests, narrative memos etc.

Using a structured google doc that we could all edit had a huge positive impact. It didn’t just make conversations clear and give us a better idea about what we should build, but it had some other unforeseen positive effects as well:

We effectively got rid of most of our meetings.

As it was asynchronous we suddenly got to spend enough time to respond to hard questions, avoid loud managers overwhelming meetings or getting side-tracked into unnecessary arguments. We could use the document to refer back to decisions that would otherwise be conveniently forgotten.

The template

To make the transition smooth I wrote a template and a guide for the whole team. Here’s how it looked like as it was first shared around. Please make it your own and let me know how it goes.

What to write in a proposal? — A simple template

A typical proposal document would follow this structure through it’s life. There’s a guide bellow to help you filling it out. As a first step just copy and paste these into a new google doc and don’t worry too much if some parts are still empty. Invite a few colleagues as soon as possible and beef it out.

Title
Summary
Problem
Impact
Measure of success
“Why does this happen?” aka. The details
Current solutions
Ideal scenario
Constraints and needs
Unknowns
Proposed change
Alternatives
Technical specification
Rollout plan
What’s left after implementation?

Guide to the different sections of the template

Summary: The most important bit when summarising the problem, is its impact on the business.

E.g.:

Problem: We cannot reliably provide old statements to retailers.

Impact: Our partners are frustrated. The team is wasting time to retrieve the statements. Our accounting becomes a painful process.

Measure of Success: Success is at 0 tickets/emails requesting old statements.

Focus on the affected stakeholders and try to quantify the actual impact: If I change this, I should see this. It’s key to be able to measure the impact a change will bring. This may be with specific metrics (e.g: 20% increase in sales) or implicit gains (e.g: customer support will be sleeping better at night). As long as the impact is defined beforehand, we can validate through quantitative or qualitative evidence if we were successful!

Remember at the end of the day, changes and features are built from people to people — never forget the human element.

Details aka. “Why does this happen?”

Ask “why?” five times to get to a root clause. Assume that others are not that familiar with the topic, so start from the root when explaining! Also this ensures we are solving the right problem.

Current Solution

Describe the current solution here. Find what’s already out there, what kind of workarounds do people do at the moment?

E.g.:

To refund a customer, the team is currently doing a manual change in admin, then going to the payment provider to do the refund manually, then return back to admin to record the change.

Ideal scenario aka. Story mapping

Describe the user flow from the user’s perspective. Follow the BDD style.

E.g.:

As a user I should be able to login to use my account.
As a retailer I should be able to set an item out of stock to keep the information up to date.

Constraints and needs

List the problems (can be technical, business etc.) you have to keep in mind. And list the criteria you can use to evaluate the proposed work.

Some common constraints could be: legacy, modularity, backwards compatibility, future proofing, race conditions, dependency on third parties.

E.g.:

Creating an order should never fail, even if a shipping provider is down (Decoupling)
The solution should be sensible. Keep in mind that emails are not sent over secured channels and can be compromised (Security)

Change aka. the proposed work

After you described the current scenario and painted the ideal one you need to figure out how can we get there.

This might also mean that first we have to figure out the:

Unknowns

Almost every project has unknowns. A good rule of thumb is to tackle these first. Not just so you can know for sure that we can do it. But also because an unknown can mean that our estimates are completely off when it turns out to be a much bigger thing than we first thought.

Alternatives

You can have multiple alternative solutions, but order them from low effort to high effort. Try to show some examples for comparison of efforts.

Spec

This is probably out of scope for this document, but it’s a good idea to link it here.

Rollout plan

The steps to get things live. Generally would part of the spec. Don’t worry too much about it in the beginning, but highlight it, if it’s requires more than the usual effort.

What’s left?

After implementing the change, you may highlight it here what got left out that should be done in the future.

Guide Checklist

Keep in mind there are no good or bad answers for many of these, but you should be able to answer to all of these:

On what level, and how detailed I want to describe things?
Did I write details into unrelated sections?
Who is this document for? Do they really know all that stuff I assume?
What impact would this change have on the business?
Can we quantify it?
How do we measure that the change solved the problem? How does winning look like? (ROI, proof of impact)
What is the root cause? (“Why? Why? Why? Why? Why?”) Are we solving the right problem?
Can we break up the solution into smaller chunks to reach the goal faster?
Are we trying to solve a general problem before something specific?
How do people solve this already?
Did we talk to them yet?
What’s the ideal scenario?
What problems will the implementer face?
Is this going to be used in 3 month down?
Would this break anything? Is it backwards compatible?
Could the users work around the proposed solution for edge cases? Do we want to allow that?
How are we going to roll it out without affecting other systems?
What are the unknowns? How can we figure out them ASAP?

Further tips on how to write an effective proposal

Products are made through conversations. Typically, either due to business requirements or because of a growing pain, someone decides that there is a need for a change. The change is then discussed with a few people to validate that this change is really a good idea and should be put forward. That plan is summarised in a couple of pages and shared for further discussion.

This document aims to be a guide on how write that plan, to achieve good discussion and ultimately it’s goals.✌

Level of detail

Start out small and share it early, as time goes by the document gets more and more detailed. Sharing the document while it’s work in progress makes it easier for you to gather feedback early on and also makes it easier for others to feel like they own a piece of it. Think of your proposal as a document that matures over time, early comments are invaluable to ensure you’re tackling the problem in its entirety and from the right direction.

By the time it’s ready to implement, it might even get split into several implementation plans. It’s very important though to ABC (Always Be Capturing) so you and your team can come back to what was agreed before. It’s especially nice how you can share it with new joiners to quickly get them up to speed.

Audience 🙋

Whenever you write a proposal keep in mind that it will go through many steps and to communicate your intent accordingly with the right context and people in mind. 🐸 🐴 👾

Whatever your work is, it’s important to realise it’s part of a bigger process, perhaps such as: