What makes a great product?

@aviflombaum*

Products make something hard to do easy.

While Avi Flombaum makes great products and gives this talk, this is about how great products answer hard questions.

Start

Think about answering questions.

The products you love most are not features. They are answers. Every one of them started as a question somebody kept asking and nobody could answer well.

  1. What's everyone saying? What's everyone saying about something? What are my friends saying?

    Twitter. Three hard questions, one text box, one timeline.

    The Twitter home page asking What's happening? with a grid of trending moments

  2. Find me anything on the internet.

    Google. The biggest question there is, answered by a single input.

    The Google home page: a logo, one search box, two buttons

  3. Is there a couch in Brooklyn I can rent tonight?

    Airbnb. Where, when, how many. That is the whole front door.

    The Airbnb home page: Book unique homes and experience a city like a local, with a where, when, and guests form

  4. How can I get messages in front of my users who are doing certain things?

    Intercom. A question only a company would ask, answered so plainly that the marketing page draws it as a doodle.

    The Intercom home page: Communicating with customers shouldn't be this hard, showing the old way and the new way

Great software answers hard questions.

It makes work faster by providing what you need, when you need it.

Notice what the four screenshots have in common. None of them look hard. A text box, a search field, a form with three inputs. The question is enormous and the surface is tiny. That gap is the product.

So when you look at your own product, start there. What question does it answer? If you cannot say it in one sentence a stranger would recognize, you do not have a product yet. You have a set of features.

Slack notifications.

Should you get a notification for this message? That is the whole question. Here is the whole answer.

Slack's internal flowchart for deciding whether to send a notification: dozens of branching decisions ending in a red or green light
Slack's decision tree for a single notification. The user sees a red dot or nothing.

Everything is harder and more complex.

Hide stuff.

An iceberg photographed at the waterline, a small peak above and an enormous mass below

Great software takes a hard problem and hides the complexity of the implementation using technology.

It's an iceberg.

The user only ever touches the tip. Your job is to build the ninety percent under the water so well that nobody has to know it is there. If the complexity leaks out into the interface, the product is not done yet.

How search works.

Google's own explanation of what happens under a single search box. Tap any panel to read it.

A search box that reads How Search Works in 2016
How Search Works, part one: the user and user intent, language, location, device, search and click data, recent searches
How Search Works, part two: general ranking criteria including RankBrain, site link authority, site reputation, on-page relevancy, and integrated verticals
How Search Works, part three: penalties and filters, Panda, Penguin, ads, mobile friendliness, and duplicate content
How Search Works, part four: the search interface and results, ads, informational searches, easy to answer queries

All of that, and the person typing sees one box and a list of ten links. That is what hiding stuff looks like when it is done well.

How to make your problems into products.

A real one from Flatiron School. We needed to grade code challenges. Here is the problem, and here is the way I learned to think about it instead.

A color-coded spreadsheet used to track which students took, submitted, and passed a code challenge
Before. Grading lived in a spreadsheet, and the spreadsheet lived in one instructor's head.
The Rails Code Challenge dashboard listing twenty-four students with their status, grade, and reviewer
After. One screen: who took it, who passed, who needs feedback, who retakes.

The problem list.

  1. Giving out the code challenge.
  2. Students taking it.
  3. Instructors monitoring it.
  4. Students submitting it.
  5. Grading.
  6. Instructors giving feedback.
  7. Students getting feedback.
  8. Students taking it again.
  9. Silos of information.

This is where most teams start, and it is a trap. A list of problems produces a list of features. Nine problems, nine screens, and nobody can tell you how they fit together.

The narrative, A to Z.

  1. As an instructor, I have a code challenge I need to give to a batch.
  2. I find the batch of students to assign a code challenge to.
  3. I create the challenge they have to do.
  4. The student then needs to do the challenge and submit it.
  5. As submissions come in I need to monitor the status of submissions.
  6. Once the submission deadline has happened, I need to grade them.
  7. I need to convey feedback back to the student.
  8. Some students need to retake it.

And it should be fast and easy.

Instead of thinking about problems, think about narratives.

I tell myself the story over and over and over and over again until I can see it.

I try to see the story and the people and the problems and the information from every angle and every facet.

A narrative has a person in it. It has an order. It has a beginning, where someone needs something, and an end, where they have it. The problem list has none of that. When you tell the story enough times you start to notice what is missing, what is out of order, and which steps the person should never have to think about at all.

The nine problems turned out to be one story with eight beats. The product is that story, made fast and easy.

A dark, many-faceted crystal glowing from within, seen edge on
Every angle and every facet.

I think about products and workflows all day every day.

The story has to leave your head and land on paper before anyone can build it. This is what that looked like for the code challenge tool, in the order it happened.

  1. Write it down.

    The first spec was an email. Then a problem statement, goals, non-goals, success metrics, and the feature requirements that fall out of the narrative. Writing is where I find out whether I can actually see the story.

    An email describing the assignments feature, its workflows, and how instructors and students move through it
    A written assignments spec: problem statement, goals, success metrics
    A second page of the assignments spec listing feature requirements

  2. Sketch it.

    Notebooks, not tools. Drawing the screens by hand is the cheapest way to find out the story has a hole in it.

    Three spiral notebooks covered in hand-drawn screen sketches and notes

  3. Wireframe it.

    Every beat of the narrative becomes a screen. Pick the students. Create the assignment. Add the tasks. The sticky notes are the questions that showed up once the story was drawn.

    Wireframe: Students for New Assignment, a table of students with checkboxes and sticky-note annotations
    Wireframe: Create an Assignment for 22 Students, with title, description, assign and due dates, and instructors
    Wireframe: adding a task to an assignment, with type, title, lab URL, submission method, and rubric
    A map of every wireframe in the assignments flow laid out as a grid with annotations

  4. Spec it.

    Now the spec is a real document: problem statement, goals and non-goals, success metrics, and requirements someone else can build from without asking me.

    A one-page spec titled Updating Coaching Journey Steps with problem statement, goals, non-goals, success metrics, and feature requirements

  5. Design it.

    Only now does it get pixels. The design is the last step because by the time we get here, everyone already knows the story.

    The finished Rails Code Challenge dashboard for twenty-four students
    The finished single-student view showing tasks, grade, and reviewer

Product influences process.

The way you build should come from what you are building. Not the other way around.

Tweet from Ryan Singer: When product managers are downstream of requirements they become project managers. To impact the product you need to influence requirements.
Ryan Singer, September 2017. If you only receive requirements, you are managing a project, not a product.

Build evenly.

I can log in via three different auths.

I can create a deck.

And I can vote on a deck.

Can I create a tournament?

Build evenly across your features in terms of breadth and depth.

Three ways to log in and no way to run a tournament is a product that is deep in the wrong place. Before you go a level deeper on any one feature, ask whether the whole story works at the current level. Usually the next most valuable thing is the beat that is missing, not the beat that is thin.

Process: finding the right balance.

A diagram of the Agile Scrum framework: product backlog, sprint planning, daily scrum, sprint review, sprint retrospective
Not this. A framework you adopt whole is process that arrived before the product did.
Pain against amount of process: a U-shaped curve. Pain is high with not enough process, drops to a minimum in the middle, and rises again with too much process. Pain Not enough process Too much process Aim here

Try to maximize:

  • Communication
  • Efficiency
  • Quality outcome
  • Flexibility
  • Team happiness

Too little process and nobody knows what anyone else is doing. Too much and the process becomes the work. The bottom of the curve moves as the team and the product change, so you have to keep looking for it. The five things above are how you know you are close.

Thanks.

If you only remember five things:

  1. Products make something hard to do easy.
  2. Great software answers hard questions.
  3. Hide the complexity. It's an iceberg.
  4. Think in narratives, not problem lists.
  5. Build evenly, and let the product shape the process.

Avi Flombaum, avi.nyc. The original deck is here as a PDF.