View profile

methodical product design - Product Definition

IMPORTANT UPDATES (or just Updates) 1. Bi - Weekly Newsletters: Why? Because of this tweet. Well, not
methodical product design - Product Definition
By Akar Sumset • Issue #9 • View online
IMPORTANT UPDATES (or just Updates)
1. Bi - Weekly Newsletters: Why? Because of this tweet. Well, not just that but also your feedback was that it takes too much time to read the whole thing. So, let’s try bi-weekly cadence.
2. Sunday Newsletters: Main issues like this one will be shared on Sundays. Reason? Same as above. I might occasionally share mid-week newsletters. Terms and Conditions apply.
Definition & Design is the most hands on part of Product Design and Development process for product people. 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 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. So, again, let’s see what the high level process looks like and what methods, tools, guides are there to help us actually get it done.

The Reason Why Product People Exist
With the last issue, we’ve completed the Discovery part of 5 D’s. There is a common misconception about Destination and Discovery that if we work very hard during those stages then the Design & 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, Destination and Discovery mostly describes the problem. We only 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. 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, too) 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. 

New Subscribers! Read This First
Before we dive deep in Definition, here is a recap of 5 D’s of Product Design & Development framework of mine, especially for new subscribers. 5 D’s covers the 5 main stages of product design and development:
  1. Destination: Vision, Strategy, Roadmap 
  2. Discovery: Inspiration, Ideation, Testing
  3. Definition & Design (You are here)
  4. Development
  5. Data and Optimization
Definition, together with Design, is the part we shape the product. Think of prior steps (Destination and Discovery) as the clay for a ceramic jug we want to make. Then, Definition and Design is where we shape the clay into a jug. And then, Development is the part where we bake the clay shaped jug to get a ceramic jug. Finally, when the ceramic is ready, then we can smoothen the edges, paint it however we want and make it even better, similar to what we do with Data & Optimization process.
What do we mean by 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 support 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.
Why do we need Definition?
from: Stack Overflow
from: Stack Overflow
0. Scaling communication
Obvious, isn’t it?

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 the paper our brains read and evaluate what’s written. Then we write down the evaluated version and bam! It’s much better than the original idea.
Another benefit of writing is that it forces you come up with logically strong claims, or in our case definitions. 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. (The 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 these newsletters.)

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
Simply, we should approach this problem (the problem of people not reading documents) similar to how we approach user experience. We should design our co-workers’ experiences. It’s unbelievable how this gets ignored. The people who we work with are PEOPLE! 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. Jargon free.
  • Show don’t tell. Prototype, act out, present interactively. Only and only then hand out the Definition. Otherwise, preconceptions will trump what you actually mean.
  • Involve colleagues early on and sincerely listen to their feedbacks. So that they get engaged from the beginning and you do a much better, spotless Definition.
Elements of Definition
An incomplete list of common Definition elements in no particular order.

  • Overview
    • Summary: What is this thing we are doing and why.
    • Added Value: The value we create for users and/or the company. (Not a list of functions but the value those functions produce.)
    • Overview Visual: A diagram, a prototype or anything visual to help convey the what.
    • Highlights: Anything needs specific emphasis.
    • Future Ideas: How can we improve in the future.
    • Dates: Deadlines, demo dates etc.
    • Stakeholders: Who is involved? How?
  • Business & User Requirements
    • Use Cases: Main cases why our products exist for.
    • User Stories: A general, concise, description of a product/feature/functionality.
    • 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.” Contrast this to a user story and you’ll get the idea.
    • Acceptance Criteria: Details of user stories. (How things work, look and perform)
    • User Flow: Visualization of how users navigate through.
    • Test Cases: How to test if the product is working as intended.
    • Metrics: What to track and how to track them.
    • Design Notes: Specific design expectations.
  • Technical Requirements
    • State, Class, Object, Sequence etc. Diagrams
    • Database Model
    • Security Requirements
    • Server Structure
    • API Documentation
    • Interfaced 3rd Parties or Internal Applications
Goodies: Methods, tools, guides
Painless Functional Specifications - Joel on Software
UX Design Methods & Deliverables
Lean Requirements
What is a Job to be Done (JTBD)?
Documenting the Design of Rich Internet Applications: A Visual Language for State
On Writing Product Specs
Use Case Examples -- Effective Samples and Tips
A shorthand for designing UI flows – Signal v. Noise
Have a great Sunday!
Not like this.
Not like this.
Did you enjoy this issue?
Akar Sumset

Hey product person! Can't choose what to read? Can't trust what you learn? Methods (frameworks, guides, principles...) are the solution if you know when and why to use them. Unlike other newsletters, Methodical shares content in a structured way so that you know when to use what.

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Disbudak St. 17, Besiktas, Istanbul, Turkey