What is Product Definition
And How to Define Products To Get Everyone Willing to Build It
Definition together with design (more precisely, sensory design)is the most hands on part of Product Design and Development process for product people. This is the part where most of the back and forth happens, where everything seems very clear until we figure out that it is not, where it feels like a never ending spiral. And that’s normal. That’s perfectly fine if we have our methods and principles to get us through. Otherwise… it’s a total nightmare… an absolute chaos… which kills us slowly…
OK. I’m exaggerating but you know the feeling. The uncertainty of the process can become terrifying. And don’t forget the deadline pressure and development team utilization issues since they all depend on our product definition. This is quite big of a pressure to handle. And with pressure comes mistakes like gaps in the flows, overlooked edge cases, missing screens, weak copy, unaligned departments and so on and so forth.
I’m by no means a fan of comprehensive, ultra detailed, tome like documentation. However, what I know to be true from my own experience is that having simple templates, a checklist and a lightweight playbook will greatly help with, well, slowing down your hair going grey. If you are a product person there is no escape from grey hair. But at least you can slow it down :)
So, let’s see what the high level Product Definition process looks like and what methods, tools, guides are out there to help us with grey hair issues.
“But we did user research”
There is a common misconception about product strategy and discovery that if we work very hard for those then the definition of the product will be very straightforward. Well, if that was the case then there would never be a Google Graveyard (projects Google killed).
Why is that so? Because, strategy and discovery mostly describes the problem not the solution. We barely scratch the surface of the actual solution during the late stages of discovery. Problem definition and early testing are extremely crucial to define and design the right product. That’s a fact. However, they are by no means a step by step guide that we can follow to define and design products.
Why? That’s because those stages focus on user feedback and company goals to define problems. And we all know that users and companies do not know what PRODUCT they want. They only know what RESULTS they want. It is our job to build the product to provide them with the results they want. That is why we the product people exist.
Definition, together with design, is the part where we shape the product. Think of prior steps (strategy and discovery) as the clay we use to make a ceramic plate. Then, definition and design is when we shape the clay into a plate. And then, Development is the part when we bake the clay to turn it into ceramic. Finally, when the ceramic is ready, we can smoothen the edges, paint it however we want and make it even better. Similar to what we do with optimization.
Defining Definition
In essence, Definition means writing things down. Things?
“Why are we building this? How is it going to work? What will it look like? How do we know we are successful? What 3rd parties are we using? Who is the tester? What faq articles do we need? When should we launch it? What comes next? How do we launch this?”
Definition answers all these questions and even more.
Obviously, details change from company to company. Some companies like Microsoft might need full time people responsible of hyperlinking help documents or others like Product Hunt can spec out the whole vision and the interface details in seven pages. The important thing is that they are written down, accessible, readable, maintainable.
What is the use of Definition?
0. Scaling communication
As seen above, there is a super-linear relationship between the number of people in a team and the possible connections between them. In order to have visibility and alignment, we need things to be written down.
1. Thinking things through
Writing, especially in a structured way, helps a lot with thinking things through. (Read this awesome story if you don’t believe me.) People who write know the feeling. It’s like observing your thoughts from a third person point of view. It actually is true since while putting words on paper our brains read and evaluate what’s written. Then we write down the evaluated version and voila! It’s much better than what we originally thought of.
Another benefit of writing is that it forces you come up with logically strong claims. During a speech, we are armed with gestures, intonation, mimics etc. to make our point or even to cover up our mistakes. Additionally, it’s not easy for listeners to spot inconsistencies in a speech since they simply forget what’s been said before. (human attention span has decreased significantly thanks to the smartphones.) But it’s totally different when it comes to reading. People are more attentive while they read and can easily refer to what’s been said previously. So, how can one know all these and write sloppy definitions? (This is one of the reasons I write.)
2. Developing a common understanding across teams
Consistency is key to a better experience, usability and trust. To sustain consistency we need principles, guidelines and design systems for sure. But they are just the beginning. If we do not follow them on each and every product/feature/backlog item we work on then they are useless. That’s why Definition is so crucial. When things get written down in a single source of truth fashion then we get the basis to build up on. Not only as product designers and developers but also as a company. Marketing, customer support, legal, sales… all these different teams get to see what’s being built and why.
These are all great benefits. However, we all know that nobody reads documents. So, what do we do? Read on.
How to approach Definition
We should approach this problem (the problem of people not reading documents) similar to how we approach user experience. We must design our co-workers’ experiences. It’s unbelievable how this gets ignored. The beings who we work with are HUMANS! It’s only human to get distracted/bored/disengaged if what we consume isn’t well designed for our specific needs.
To my experience the best approach would include;
- First, give the forest (an overview of what’s being done meaningful for everyone regardless of their role) then the trees (specific details tailored to specific roles like developers, marketers, sales etc.)
- Visualize as much as possible. Use flows, images, moodboards etc. to convey meaning. Use them as early and as frequent as possible.
- Be concise. Avoid jargon.
- Show, don’t tell. Prototype, act out, present interactively. Only and only then hand off the Definition. Otherwise, preconceptions will trump what you actually mean.
- Involve colleagues early on and listen to their feedbacks, sincerely. In order to get them engaged from the beginning. This will help you create a much better, spotless Definition.
Elements of Definition
Below is a list of common Definition elements with examples. Let’s see what it would look like if we were defining “Load Money Using Credit Card” feature for an existing e-wallet.
Keep in mind that examples are extremely simplified for this article. Their actual purpose is to help you get a better idea of what elements look like rather than actually defining a product. However, I’d argue that a passionate and collaborative team could easily develop a product using the following simple definition.
Example Feature Name: Load Money Using Credit Card
Overview
Summary: Explains what this thing we are doing is and why we are doing it. Summary should be written in a reader agnostic fashion so that anyone in the company can understand. That holds true for all Overview elements.
Example
We’ll enable our users to load money into their wallet using credit cards. This will help them to load money faster and more importantly send or withdraw money even though they don’t have cash in their bank accounts.
Added Value: The value we create for users and the company. This is not a list of functions. Rather, the value those functions produce for the user and the company.
Example
User Value: Faster money loading. More options for loading money.
Business Value: Increased user satisfaction. Increased transaction volumes.
Overview Visual: A diagram, a prototype or anything visual to help convey the what. A picture is thousand words, right?
Example
We are the Merchant here.
Highlights: Anything needs specific emphasis.
Example
1. This feature is very important for our upcoming press event as it’ll be held in the XYZ conference.
2.This will be a proof of concept for using React Native in our app.
Future Ideas: How the product can be improved in the future. Simple explanations or links to inspirations are mostly enough. This helps both designers and developers to design better architecture for future iterations.
Example
Recurring Load: We may introduce this feature for the frequently loading users so that they can automate it and save time. Similar to what PayPal does with recurring payments https://www.paypal.com/pdn-recurring
Dates: Deadlines, demo dates etc.
Example
This is expected to be launched during first half of Q2, 2017. We foresee at least 1 months of a beta process.
We’ll need a front end only prototype for the internal demo gathering on 13 February 2017.
Involved Parties: Who is involved and how are they involved? Using RACI matrix is one of the ways to map involved parties out.
Example
RACI
Business & User Requirements
Use Cases: Main cases why our product/feature exist for. Our “Load money using credit card” example is a very simple one. So, we only have just one.
Example
Load Money
Customer Stories / Jobs to Be Done: “People don’t want a drill they want a hole in the wall so that they hang their pictures and make their place more home like.” This quote explains the concept very well. Simply put, Jobs to be Done first focuses on why users need/want to perform certain tasks. Then uses it to define the how.
Example
I impatiently want to send money to my daughter who studies abroad because this is the rent day so that I can show I can be there for her even though we are continents apart.
Forces
I am anxious because she might feel lonely.
I am nervous because it might take too long for her to receive the money.
I am nervous because I might not have enough cash.
I am nervous that it might cost too much to send the money.
Looking at the example above, it’s very obvious what needs to be highlighted during loading money. Also, since we now the situation, it’s much easier to empathize, either.
User Stories: These can be thought as step by step definitions for each use case. (To be honest, I can’t say I’m a fan of user stories.)
Example
1. As a wallet owner I want to use my credit card to load money so that I can send money to my contacts.
2. As a wallet owner I want to save credit cards to load money faster.
3. As a wallet owner I want to use card scanning to add cards faster.
Acceptance Criteria: Details of user stories or customer stories. Mostly, used to describe details like look and feel, performance requirements and other details.
Example
Adding Card Acceptance Criteria
1. There should be an informing splash screen teaching user how to use camera in order to scan their card.
2. If it takes more than 1,5 seconds to process the card image, user should be shown a friendly message.
3. Users can add up to 5 credit cards.
4. Using the BIN database, we’ll show if the card is VISA or Mastercard.
Not Doing: This helps with preventing possible harmful assumptions so that we are more focused.
Example
We’re NOT going to let users load money using debit cards.
We’re NOT going to let users load money using non Single Euro Payment Area credit cards.
Task Flow: Visualization of how tasks occur. We looked at the general task flow with the Overview Visual above. So, let’s see how 3D secure and risk control would work when loading money.
Example
Test Cases: The conditions we need to test to ensure the feature works as intended. One way to define test cases is using Given When Then framework.
Example
Metrics: This is the part where we define what data we need to accumulate and how. Then how to interpret this data and understand if we hit our targets. There might be several targets like conversion rates, transaction volumes, user satisfaction... Our example will cover business and user experience design related metrics.
Example
Business Metrics
Month over month increase in load money transaction volumes.
Target: %X increase
How to Track: Separately, aggregate money loaded using credit cards.
UX Metrics
Add card completion rate.
Target: %Y.
How to Track: Send following events to Google Analytics
Design Notes: Specific ui design expectations. These can be things that inspire you or things you find very important as part of ui design but feel that it’s not emphasized as needed in the definition document.
Example
Processing images after card scan might take up to 3 seconds. Using a fun loading screen might mitigate users’ getting bored.
Our fees are the lowest among the competition. This needs to be highlighted.
Interface inspiration
Conclusion
This is by no means a complete product definition format. This or any other documentation format won’t guarantee you a painless development process, either. A digital product is a like a living organism. It doesn’t stop evolving after we complete our definition. We get lots of feedback during implementation, change our minds after seeing demos or come across some occasions that require us make trade offs. The gist is this: Purpose of definition is not to get developers implement exactly what’s described in it but to get the whole company collaborate based on the same knowledge and work towards the same goals.
This seems like a dilemma but it is not if we follow the Agile Manifesto:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
Related References
Painless Functional Specifications
UX Design Methods & Deliverables
What is a Job to be Done (JTBD)?
Product People, Mind the Gap! — UX of User Onboarding
Documenting the Design of Rich Internet Applications: A Visual Language for State
Use Case Examples — Effective Samples and Tips
A shorthand for designing UI flows — Signal v. Noise The Nine States of Design
