The Product-Minded Engineer

Chapter 1. The Foundations of Product Thinking

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 1st chapter of the final book. Please note that the GitHub repo will be made active later on.

If you have comments about how we might improve the content and/or examples in this book, or if you notice missing material within this chapter, please reach out to the editor at [e-mail].

Engineers are torn between two masters: the users and the system, psychology and physics, the organic and the inorganic. Those two masters are like competing puppeteers, and we are the puppets between them being held aloft by their threads, constantly being tugged in opposite directions.

For me, this tension is the beautiful part of software engineering. Finding that design that both caters to user needs and, say, the vagaries of distributed systems is immensely satisfying.

Some engineers prefer to avoid this tension. They focus on building elegant systems to the exclusion of thinking about users. They are like prairie dogs who build beautiful tunnel systems underground that are resilient to flash flooding, protected from large predators, and offer good air circulation. But even prairie dogs have to poke their heads aboveground sometimes to surveil for predators. Like engineers, they have to “look up.”

But how to do both? We have enough on our plates just thinking about abstractions and design patterns, scalability and race conditions.

It’s easy enough to pay lip service to “think about users” or “users first.” We’ve all heard that advice. But how do we do it systematically and with the level of rigor that engineering requires? How do we do it efficiently enough to squeeze in as we code, design, and plan?

In this chapter I’ll discuss the foundations of systematic product thinking. In the first section, I’ll survey the practice of looking up in every aspect of the software lifecycle. Next, I’ll introduce the scenario--the user story—​which will help us think concretely about users across all these phases. Finally, I’ll mention some generalizations about human psychology that you can use even before you learn how to hack into the brains and needs of specific customers.

Look up early and often

Have you ever spent two hours coding up a class or a module, only to start testing it and realize that you missed some key requirement? I’ve crawled out of many such holes. When I’m lucky enough to get into a “flow state” while programming, it’s easy to lose sight of my objectives.

To some extent, that’s natural and inevitable. We need distraction-free times where we can just create. And yet, experienced engineers can hop back and forth between user thinking and system thinking at will in all phases of software lifecycle. Let’s survey what alternating between looking up and looking down entails, starting from the beginning of a project.

For this story, I’ll pick on a game infrastructure developer, Ainsley aka “Ains”, who works on a popular first-person shooter. They own the matchmaking service which groups people together into online matches. This service is called by the main application’s online match launch screen when users click “Play Online”. Betty, the product manager, tells Ains that users are complaining about laggy matches and hopes matchmaking can help by pairing up gamers who are close on the network to one another.

As the story unfolds, watch as Ains alternates between user-thinking, labeled “Up”, and system thinking, labeled “Down.”

Up: Ains isn’t sure if Betty’s report is anecdata or widespread and resolves to correlate ping times to how long people stay in matches.

Down: Ains instruments the matches to determine ping times, which they had no data on.

Up: They chart the two axes against one another and notice a steep dropoff in the length of game as the pings slow down. In particular, there seems to be a steep dropoff at round-trip latencies above 50ms, and a good 12% of matches fall into this bucket. This gives the team confidence that incorporating latency checking into matchmaking could help.

Up: Ping latencies are not the only factor to consider. Ains and the producer get together in front of a whiteboard to decide how to weight pings against the existing traits of skill and personal toxicity (earlier, the game designers decided that people who’ve been tagged as abrasive get matched with one another.)

Down: Ains designs new matching math that prioritizes toxicity-matching first and then skill and latency after that.

Up: Ains practices test-driven development (TDD), so prior to coding, they write some tests for various matching scenarios based on the requirements. They make sure, for example, that a fast ping will not cause a toxic user to pair with a non-toxic one, and many other requirements.

Down: Ains implements the new criteria and gets the test passing. They use a feature flag so that they can carefully roll out the functionality.

Down: They still need to make test pings between the people looking for matches so it can be fed into the matchmaking criteria. Stoked at the rare opportunity to design an actual algorithm, Ains designs a simple one. When a new person joins the pool, they will send pings to up to fifty other machines, wait a few seconds for results, and then that data will be grouped and uploaded to the service.

Up: Another team, the game app team, owns the online match launch screen. Ains works with them to design the interface they will use to gather the data and then pass it along into matchmaking.

Down: Ains builds and tests the new interfaces.

Up: Ains does a naming and commenting pass of his code, making it easier to code review and maintain.

Down: After committing the code and rolling out the new service, Ains flips the feature flag on for an experimental group.

Up: Complaints trickle in from the Discord forum. Some people are getting “starved"--they aren’t matched with anyone. Ains instruments their code and learns that latency is the most common reason for starvation.

Down: Ains implements a gradual loosening of the criteria, such that the longer somebody has been awaiting for a match, the looser the latency and skill requirements. This change gets rolled out. They also add an error message to tell people when networking is the issue: “Sorry, your ping is not fast enough to get matched with anybody.”

Up: Users start complaining about getting this error message and Ains is crushed to see two people give up on the game entirely. Somebody suggests that Ains make his error message more actionable by suggesting remediations for slow connections, such as turning off or switching their VPN. Ains makes the trivial change.

Down: Once the community forum seems stable, they roll out the new matchmaking algorithm to everyone!

Up: The team dashboard shows a 7% increase in match length based on the change and a 15% decrease in matches the end within the first minute.

Such is the launch of a successful project, traveling along peaks of user empathy and deep valleys of coding work.

Also typical for an infrastructure engineer is Ains’s need to keep various sets of users in mind. They must write maintainable code for their team, good interfaces for the teams in the application layer, and yet the app team does not insulate them from thinking about end users. While nominally “closer to the users,” the app team doesn’t understand matchmaking enough to make those decisions. The PM wasn’t a cure-all either—​they helped with the initial user research, but most of the details were left to Ains.

Throughout this book, we’ll touch on all these phases of the software lifecycle and show how to use product thinking to achieve great outcomes in each scenario. In the rest of this chapter, we’ll continue to talk about universal product skills that can be brought to bear in any situation.

Scenarios

A scenario is an illustrative user story and is one of the key concepts that drives good product thinking. In this section, we’ll break down and analyze the components of an effective scenario.

But first, I’d like to motivate why scenarios are useful. It’s only fitting that I do that with a story.

The first attempt

Let’s visit Bob, a mobile app engineer for a 300-store coffee and tea chain called O’Rei Tea. He’s three years into his career. His app supports a mobile ordering experience, and he’s received feedback asking for a “favorites” option so that users’ preferences can be remembered for quicker ordering. The team’s goal is to increase orders, so they prioritize this. Bob has been talking to Carlos, his manager, about a promotion, and Carlos says that if he can move some metrics, it’s a likely thing.

Bob looks over some user feedback that came in through the app’s feedback widget. Coffee drinkers are tired of re-specifying their customizations each time they order, and they don’t like digging through their recent orders. Sometimes, the item they want is buried within an order that had several other items, and it’s tedious to split out.

Bob works up a mock that works well within the app structure (Figure 1-1). He’ll add a menu item for Favorites to the bottom of the app and add a new page that lists users’ favorites. It has a button in the upper right for adding a new favorite.

Figure 1-1. Bob shows his proposed mobile app changes. New elements are shown in green.

Happily, this will be easy to implement because the favorites list uses existing menu widgets. Once drinkers click Order, they’ll be dropped into the existing shopping cart experience.

The new favorites database table will be sorted by most recent purchases, and Bob specifies the (SQL) database schema and notes that it will be indexed by recency for quick querying.

Table: favorite_items
- created_time : timestamp
- updated_time : timestamp (Index)
- item_id : long
- milk_customization: varchar
- sweetness_customization: varchar
- special_instructions: varchar

What do you think of this design? What suggestions would you make if you were in a meeting with Bob? For now, hold on to those thoughts.

Bob also proposes that they replace the new product advertisement on the home screen with favorites, but the “New Products” team shoots the idea down because they need a place to drive awareness of their new drinks. He grudgingly cuts it out of his design.

There’s a big review meeting and everybody likes the design, in particular that it’s cheap to implement. One person notes that the Starbucks app has “heart” buttons on recently ordered items and in the shopping cart. Why not have a similar button that adds items to Favorites? But Bob pushes back, noting that this button will double the time-to-implement since it’s a more invasive change, for example adding a new database query on several pages. The team agrees and the project is built and shipped as designed.

Meh results

Reviewing the data a few weeks later, there’s good and bad news. The good news is, it shipped without major bugs. Unfortunately, it doesn’t give much of a lift. Only 6 percent of users utilize favorites at all, and total coffee orders increase by only 0.3 percent, which isn’t statistically significant. Bob’s not sure exactly what he hoped for, but he doubts Carlos will promote him based on this result.

O’Rei Tea is a modern, data-driven shop, and the app is well-instrumented, so Bob digs into the data and finds that few people are clicking into the Favorites menu, and many of those leave immediately. The ones who have no items in Favorites are overwhelmingly likely to leave rather than click the + button.

Bob thinks back to the “heart” button idea and meets with Carlos, his manager, to propose adding that to increase conversion. Unfortunately, the team priorities have shifted to monthly subscriptions, and there’s no time to build it anytime soon. Carlos seems annoyed with his proposal, and Bob leaves feeling like he is not being allowed to finish his product.

A second attempt

Six months later, Bob’s still working on subscriptions when Alice, a more senior engineer, is brought in to build the heart button that Bob regretted not building. She doesn’t stop there—​she also builds a concept of favorite stores. Now, users who frequent a particular store can skip click in the checkout flow—​something that Bob hadn’t even considered since he had been asked to focus on favorite drinks. Finally, she A/B tests a change where the new product promotion on the home screen is replaced by a huge pair of “order now” buttons, plus a peek at the top of a third button to indicate that scrolling is possible (Figure 1-2). It’s similar to the design Bob had thought of, but he hadn’t been able to convince the product marketing team.

Figure 1-2. Alice mocks up a scrollable quick-ordering screen with

Over time, Alice’s experiment demonstrates that these changes will combine to increase conversion by 3.8 percent. Since mobile orders account for the majority of O’Rei Tea’s revenue, this is enough to make a substantial impact on the bottom line! Armed with this data, Alice is able to convince the marketing department to drop their new product ads down in the list below the top two favorites and to roll out her test to everyone.

Post-mortem

To be fair to Bob, he did many things right. He listened to user feedback. He drove a metric. He collected user interactions and studied them. He cut scope and made an efficient, achievable, and stable design. And yet Alice made 12x the impact he made in not much more time. Bob’s only consolation is that Alice shipped a memory leak that slowed down the app for a couple of weeks.

Bob wasn’t very involved in her planning and wonders how Alice had such good intuitions for what to build, and how she convinced people to let her do it. So, he asks via text. In response, she replies with the following story:

Antonia is a busy professional who gets a chai latte with soy milk every morning on her commute. One morning, she forgets to enter the order before she goes. While she’s driving, she hits the voice assistant button in her car’s steering wheel and says: Order my usual from O’Rei Tea. Siri replies back asking her to confirm the amount and location, and she agrees.

Bob types, “Okay…​ But that’s not what you built?”

“I know. Don’t remind me,” she replies. “I tried, but Carlos thought it was too expensive to build. But at least I got it down to two clicks.” After a pause, she continues. “That was my after story. Here’s the before story, if you’re curious.”

Antonia is a busy professional who gets a chai latte with soy milk every morning on her commute. One morning, she forgets to enter the order before she goes. While she’s driving, she comes to a stop sign and opens the O’Rei Tea app and clicks Favorites. She finds her latte at the top of the list and clicks Order now. A car behind her honks, so she moves forward and focuses on driving. But she really needs some caffeine, so when she gets to the freeway onramp, she pulls over to the shoulder. On the shopping cart page, she selects “Order and Pay.” This page asks her to select a location. Once the map loads, she jabs her finger at the Main St. pin and clicks to Pay with her most recent credit card. Finally, she clicks that and then uses face ID to confirm the payment. She puts her phone down, checks for oncoming cars, and merges back onto the onramp.

Bob winces as he reads the implicit criticism of his design. “Yeah, okay, fair,” he musters, but then he can’t contain his defensive instincts and blurts, “But how did you come up with that? Is ordering while driving really that important?”

“I kinda wish we had location tracking data to figure that out,” Alice replies. “But mostly, I interviewed a dozen of my friends and acquaintances and asked them in a silly level of detail about their coffee ordering experiences. Antonia is a stand-in for busy, scatter-brained person in a crazy morning."

Bob takes a deep breath. “I see. Oh—​Kudos for getting the heart button added,” he offers. “I tried to convince Carlos to fund it, but he wanted me on subscriptions.”

Alice sends a smirk emoji and says. “Unlucky timing,” she said. “Though, I had a scenario for that too. Here’s the before story.”

Antonia is a lactose intolerant, newish O’Rei Tea customer who remembers she liked the drink she ordered before. Intending to reorder, she sees the Faves menu, but she never put anything in it. She sees the + button but would rather not remember and replay all her customizations, so she clicks into recent orders and notices it was called the the Tiger Chai Latte which she customized with soy milk. She had also reordered a pastry she doesn’t want now, and annoyingly, reorder tries to foist that upon her, and she sees no way to select out the latte. She exits and goes into the usual ordering flow. When she gets through her customizations and orders, she looks for a favorite button at the end, but she doesn’t find it. Well, at least her latte is on the way—​maybe another time.

Bob winces once again. Why didn’t Antonia just go back and click the damn + button? When he mentions this, Alice asks him if he thinks the story would be common, and he has to admit that, yes, it would.

She sends the after story:

Antonia is a newish O’Rei Tea customer who remembers she liked the drink she ordered before. Intending to reorder, she clicks into recent orders, notices it was called Tiger Chai Latte. She clicks the heart next to it. This reroutes her to the Favorites menu, which lists it at the top, and she clicks the “Order now” button.

“These stories were my guiding lights,” she explains. “They gave me conviction that I was building and advocating for the right things, and they helped Carlos buy in as well. Though, TBH, I’m not sure if he would have believed me if I didn’t have user quotes to back it up.”

What’s in a story?

How did you experience Alice and Bob’s tale? What thoughts did you have on Bob’s initial design, and then when you read Alice’s stories?

In seeing Bob’s initial design and looking at the mockups, you might have felt unequipped to critique it or that you lacked context. Perhaps you had some ideas on how to improve it based on prior experiences. Perhaps you were focused on the database schema, questioning how the drink customizations were modeled or wondered why they were using an integer for item_id rather than a string. If you did have ideas akin to the ones Alice tried, in real life, you might have felt uneasy about proposing them since Bob seemed to have invested time into a specific design. What you probably weren’t thinking was about voice assistants or favoriting locations.

What about Alice’s stories? When I read of Antonia using the voice assistant, first of all, I wanted that in my life. But I also wondered, as Bob did, how common or important ordering from the car was. I wondered how many people had access to voice assistants from their cars, and whether Alexa, Siri, and Google Assistant were even capable of doing what she envisioned.

When I read her before stories, I felt Antonia’s stress and wondered whether anybody would actually go through all that trouble to order a coffee vs just grabbing a cup from the microkitchen when they got to work.

The questions I had reading Alice’s stories were productive questions. They would help a team narrow down and prioritize different features. She both made me unhappy with the current app and set a high bar for ease of use, and her team could measure their ultimate solution by how close it got to achieving that mark.

The questions Bob elicited from his team during the Big Meeting were interesting, but weren’t the most impactful. He went straight to specifying implementation details when more discovery work was needed. Put another way, he took a project where the most challenging parts were product decisions, and the way those choices interacted with implementation constraints, and made it seem like the implementation concerns were the most important bits.

Bob thought he was moving the needle, but then Alice, via her detailed and plausible stories, recontextualized everything. If we could compare Bob’s view of the “product goodness” to Alice’s side-by-side, it would look something like (Figure 1-3):

Figure 1-3. Alice raised the bar.

Even though her initial idea wasn’t buildable, she showed how much better things could be and raised the bar. She correctly identified the biggest risk area: would users order more drinks? She highlighted the tension in the current product and demonstrated why improvements would matter.

Alice’s stories are sometimes called scenarios.

So what, so what’s the scenario?

A scenario is a story designed to illicit critical thinking about a product. It consists of two main parts: a character and a simulation of their actions as they discover and navigate a product or feature to solve their problem.

As I explore those components, I’ll start to explain why scenarios are a crucial piece of any software development practice.

Let’s start with character. A character consists of two components: a persona, which is the background information about them, and a motivation which is what they want or need from your product in the moment they’re using it.

Here’s one of Alice’s stories again:

Antonia is a newish O’Rei Tea customer who remembers she liked the drink she ordered before. Intending to reorder, she clicks into recent orders, notices the heart next to the Tiger Chai Latte and clicks it. Then she orders it.

See if you can spot the motivation and the persona.

A motivation

The first rule of thinking about users is understanding what they want.

In fiction, a character’s desires and wants carry us through a story. We root for the hero to achieve their goals and feel it when they are thwarted. In many cases, the motivation is the beating heart propelling the story. When written poorly, we complain that characters don’t do what they “would do.”

Famously, musicals often start out with a song dedicated to establishing the character’s motivation, called the “I Want” song. In The Wizard of Oz, it’s Dorothy’s Somewhere over the Rainbow. In Hamilton, it’s Alexander Hamilton’s My Shot.

Scenario users need motivation too. That helps us feel tension and release when the product works as intended to achieve their goals, and helps us evaluate whether their actions pass the smell test. If money is involved, do we feel they have enough motivation to buy our product?

Let’s drop the motivation from the scenario and see how it works.

Antonia is a newish O’Rei Tea customer. She clicks into recent orders, notices the heart next to the Tiger Chai Latte and clicks it. Then she orders it.

Would Antonia really take these actions? We don’t know. Why did she specifically go into Recent Orders and not the menu or the favorites menu? Did she set out to favorite something and magically guess that recent orders was where she could favorite things? We are left wondering if Alice, the story’s author, is a puppeteer controlling Antonia’s actions to serve her point. We wonder if the feature is really discoverable.

When we see her mental state—​that she can’t quite remember the name of what she ordered, but remembered it being good—​we understand why she want to Recent Orders and get a good feeling that it’s not only plausible but inclusive of people without great memories for tea branding.

Here’s a well-motivated story, in the sense that Antonia’s goal is clear and strong enough to warrant her taking the actions:

Antonia is a lactose intolerant, newish O’Rei Tea customer who remembers she liked the drink she ordered before. Intending to reorder, she clicks into recent orders and notices it was called the the Tiger Chai Latte. She has a little extra time, and knows herself well enough to know she’s obsessive once she likes something, so she heads to the Favorites menu, clicks the + button, and then searches for “tiger”, clicks the search result, replays her customizations—​with soy milk, medium—​then clicks okay. Then she clicks “Order now.”

This version of the story strikes me as plausible but unlikely. It highlights that it would take a diligent, avid customer to use the current favorites system.

Forcing oneself to provide a clear user motive that carries through their actions in this way can highlight bad product design.

Avoid motivations that simply say, <person> wants to use <feature X> without explaining the user’s state of mind. Here’s a weakly-motivated story:

Antonia is a newish O’Rei Tea customer who remembers she liked the drink she ordered before. She clicks into recent orders and notices it was called the the Tiger Chai Latte. She heads to the Favorites menu, clicks the + button, and then searches for “tiger”, clicks the search result, replays her customizations—​with soy milk, medium—​then clicks okay. Then she clicks “Order now.”

We don’t get at why Antonia wants that particular customization. This is sometimes called a “so that"--Antonia engages with Favorites so that she can avoid milk and to enable her new drink obsession. Without a why, we are not so inclined to question the product experience, and it comes across as reasonable, if slightly awkward.

A persona

If the first rule of understanding users is to know what they want, the second is that not all users are cut from the same cloth. They have different backgrounds and experiences that impact what they want out of our product. This character background is called a persona. Personas are a critical tool for building quick empathy for your target audience. They can be used to communicate with your team and reach alignment. They usefully highlight contrasts between sets of users.

According to Alice’s stories, Antonia’s persona is of a repeat customer who is not yet habitual. If we strip that:

Antonia notices in the item menu or in an product placement that O’Rei Tea serves Tiger Chai Lattes, which she likes. She notices the heart next to the Tiger Chai Latte menu item and clicks it to Favorite it. Then she orders it.

This story makes it hard to understand whether this scenario is relevant to our business strategy. Is Antonia somebody O’Rei Tea should care about? Only when it’s framed in terms of a user who might become a habitual customer do we see the value.

The persona also helps us understand who this feature isn’t for. The “Favorites” feature is not very useful users making their first order, so it shouldn’t be relied on as part of any new user acquisition strategy. That is, it should not be prioritized if O’Rei Tea cafes are all designed for tourists who visit once.

Personas can be multi-faceted. In Alice’s commuter story, we also learned that Antonia is a busy professional who commutes to work. This also might be an important demographic for O’Rei Tea if they are charging premium prices that wouldn’t work if Antonia were a working-class nurse.

Remember how Alice won the argument with Marketing about whether to use the main app screen to highlight new products or to provide quick access to Favorites? This decision could easily come down to a decision on which persona is more important to the company: customers who they’re trying to convert to habitual, or customers who are already fans who like to engage with seasonal flavors.

Personas come up all the time when building products and infrastructure. Here are some common ones to look for:

• Where are users in “the product funnel?” Are they signed up or not? Ever notice how websites make sign-up very prominent, but bury the widget for sign in for existing users? This comes from a recognition that existing users do not need to be as coddled as new users.

• Casual users vs power users. Suppose power users are 10% of your audience, and you ship a feature that solves a pain point that everyone experiences but is difficult to use. If your feature turns off the other 90% of users, then you’ve only solved the problem for ten percent of the folks who need it.

• Two sides of a marketplace, such as drivers and passengers. The two sides often have extremely different needs and should not be thought of as an undifferentiated blob of users.

• Coders in different programming languages. If your developer SDK is useful both for machine learning data pipelines authored by Python developers and authors of control planes written in Go, you might want to flesh out different aspects for Python than you do for Go.

Personas highlight the contrasts and complexities of building products that cater to multiple groups and are an excellent way to think more precisely about users. I’ll discuss personas in more depth in [Link to Come], showing you how to talk about them and integrate them into your team’s prioritization and design thinking. In the meantime, I’ll refer to them frequently.

A simulation

The simulation is the plot of the scenario, taking the character, in detail, through all the actions they need to complete the task. The more detailed and end-to-end the simulation, the more unlikely you are to miss key features you need to put into your design.

To recap, here’s the story with the detailed simulation:

Antonia is a lactose intolerant, newish O’Rei Tea customer who remembers she liked the drink she ordered before. Intending to reorder, she clicks into recent orders and notices it was called the the Tiger Chai Latte. She has a little extra time, and knows herself well enough to know she’s obsessive once she likes something, so she heads to the Favorites menu, clicks the + button, and then searches for “tiger”, clicks the search result, replays her customizations—​with soy milk, medium—​then clicks okay. Then she clicks “Order now.”

And here, it’s incomplete, just focusing on the new feature itself:

Antonia is a lactose intolerant, newish O’Rei Tea customer who remembers she liked the Tiger Chai. She clicks the + button in the Favorites menu, searches for “tiger” and chooses the drink.

I’ve seen many an Engineer write a scenario just like this one, skipping all the steps except the one they’re currently implementing. This version glosses over many aspects. How did Antonia remember the name of her item? How does she know to go to the Favorites menu? Doesn’t she need to customize the item? We’re nowhere close to understanding whether Bob’s version of Favoriting is useful.

Note

Tell the complete story. Don’t just focus on the feature you’re adding.

This kind of narrow, feature-by-feature thinking is how products end up crufty and byzantine.

A good simulation is like an elegant mathematical proof where every step is justified and follows logically from the previous step. It challenges the design rather than pandering to it. A bad simulation handwaves or is self-serving by highlighting only the good parts.

If this way of thinking is unfamiliar to you, you’re not alone—​most schools and coding bootcamps don’t teach user simulations. Agile methodologies emphasize scenarios—​they call them user stories—​but give scant attention to the simulation aspect.

I meet more engineers who are highly trained pattern-matchers. They see problems that seem similar to ones they’ve seen the past and call up solutions, as Bob’s colleague did when he remembered that Starbucks had heart buttons similar to their proposed Favorite feature. These solutions form a growing repository of wisdom that they can bring to bear in new companies and form.

But, if pattern-matching is what our brains magically do for us when confronted with a problem, how do we determine what problem to look at? That’s where scenarios come in: they are the directors of our attention. Detailed scenarios are fertile ground for our pattern-matchers to engage with. Each detail might make us think of something useful.

Simulations also serve to break down products into buildable pieces. If O’Rei Tea were designing their app from scratch, each step Antonia goes through to order a coffee is a separate feature that can be specified and built. I’ll show in [Link to Come] how to use this fact to build scenarios into your design process.

Finding plot holes

When you read and edit scenarios, look for plot holes.

Above all, your product is the user’s journey. Users don’t merely “use” your product, they move through it. They discover it, think of it, learn it, use it, and experience the consequences. Narrow focus on the interface itself—​the part we can see—​gives us tunnel vision.

A classic blunder is to leave out a discovery mechanism for a beautiful feature. No docs, little user outreach, no breadcrumbs from other parts of the product that lead people to find it. If they had simulated the entire user journey, starting from when users know nothing, they would spend more time on discoverability. They could get the feature in front of ten times the size of the audience with an additional 10% of the work.

People look for plot holes in design conversations, too. One telltale sign of a more seasoned engineer is if you hear them ask likely “what if” questions. “What if the customer doesn’t remember the name of her drink?” “What if she wants to add soy milk?” Such engineers are simulating scenarios, or test cases if you will, to break your design.

How to use scenarios?

Scenarios should thread through every aspect of software development, from initial discovery, as Alice did here, through implementation specs. Thus, much of this book will rely on the power of stories. You’ll use scenarios to pick good names and design hierarchies of errors and good, actionable error messages. You’ll use them to design polished features. You’ll turn scenarios into functional, integration, and end-to-end tests. You’ll communicate with your coworkers using them. You’ll ask your users for stories when they are giving you feedback. And you’ll prioritize them to guide your product roadmap.

After all, we learn stories from a very early age, dating from when our parents read us bedtime stories. We are hard-wired to read, understand, and critique stories, and as product-minded engineers, we must also learn to generate them.

When Alice explained how she’d used stories, she used the word conviction. I love this term because it describes the feeling I get when I’ve crafted the right scenarios and I develop confidence that my product is going to work. It’s the feeling I bring to conversations when I can resolve trade-offs by thinking through the relatively likelihood of different stories. And it’s the outcome of a meeting in which a bunch of engineers brainstorm a set of stories, pick the most important ones, and leave the meeting aligned on the future direction of the product.

Getting into character

Let’s dive deeper into characters. How do we make use of them?

I regularly put myself in my users’ shoes, known as shoe-shifting. I think of the “so that” in my user scenarios and pretend I have that same motivation and work from there.

Of course, users are a diverse bunch, so this isn’t perfect. In [Link to Come], I’ll discuss how to develop a more complete picture of your audience. But short of that, you can use the fact that users are people—​yes, even programmers are human. What are some universal motivations that humans share?

Pretend you’re learning a new metrics API that is used elsewhere in your company so that you can log some successes and failures. You’d like the metrics to be sliceable and diceable by a few different factors, so you’d like to tag those metrics with attributes.

I’m going to accuse you of having several basic, near-universal characteristics:

• You don’t know, and don’t care to know, the implementation details of the metrics pipeline. You would rather learn from the API itself and possibly surface-level documentation.

• You don’t want to survey the entire set of functionality in the metrics API. You want to quickly seek and find the tool for your current job.

• You’re multi-tasking and are frequently distracted. You want to be able to make progress in one or more small “work steps” as you test out the dashboard for viewing the metrics.

• You’re busy. You want to complete the task quickly.

• You want to avoid risk. If tagging metrics with “high-cardinality” data sets such as user IDs is a scalability mistake, you want that flagged for you somehow before you deploy.

• You forget things. You may need redundant clues or reminders when you come back to things months later.

A lot of these boil down to the same thing: you want to use as little brain space on this integration as possible. You want the size of the neural network your brain allocates to this task to be as small as possible and proportional to the amount of complexity in your integration.

To get into character, flip this and assume that your users have the same time constraints and type of brain that you have, just without the knowledge you gained from developing the technology yourself.

But how? Are we forever tainted with forbidden knowledge that can’t be unseen? Do we need to rely on feedback from new users to have any hope of empathizing with them?

Happily, no. While doing user research and testing with novice users shouldn’t be overlooked—​and we won’t, see [Link to Come], in practice, not every decision can be made with full data. So, you must shoe-shift from the comfort of your own desk and with your own thoughts.

To shoe-shift, I consult “Drewbie” (Drew+Newbie) who sits on one of my shoulders and can read my thoughts. He notices any time I access knowledge and memories relevant to the product. He alerts me that I might be accessing “forbidden knowledge” and I proceed as if I didn’t know it.

For a simple example, say I’m building this metrics library and adding a function called gauge which creates a “gauge metric.” Drewbie doesn’t know what that phrase means, and I realize I didn’t either until I became a part of the metrics community, meaning many new users won’t know. That will inform how I craft and document the interface.

Similarly, Drewbie will not know that high-cardinality metrics tags are not scalable, or indeed what that phrase means exactly. That leads me to simulate a user using metrics inappropriately.

You’ll use shoe-shifting a lot in the coming chapters and, hopefully, in your career.

Summary

In this chapter, I surveyed the fundamentals of product thinking for engineers and gave the following advice.

• Look up frequently during your software projects, alternating frequently between user-space and system-space.

• Use detailed scenarios to understand your users and their situations and test your assumptions.

• Think beyond the the interface and consider the user’s journey.

• Internalize some universals about impatient, busy, brain-limited users.

• Shoe-shift to empathize with users as a daily practice.

You can measure your “product chops” in a given domain by the breadth of your simulations and the level of illustrative detail you pack into them. As you read this book and practice in real life, focus on making your scenarios “bushier” in this way. When you sketch a story, do another pass to fill in more. If you get stuck, it’s a clue that develop more direct experience with your product (Chapter 4), get more user feedback ([Link to Come]), or do user research ([Link to Come]).

These fundamentals will be used throughout this book. You are welcome to skip around after this point, but I will start with naming, the most common of all product decisions. Because it’s so frequent and uses many of these skills, practicing good naming is a great route to making product-thinking instinctive.

Exercises

In these exercises, we will pretend that we work on wikipedia.org.

1. List at least two personas of users who use Wikipedia and give descriptions of each. Make sure to consider what those users value. (My answer will cover two broad personas.)

2. Wikipedia wants to improve the health of their articles, particularly in less popular languages. Today, if users want to edit content, they must log in and click an “Edit” link. Should Wikipedia provide a slick inline editing experience that avoids this friction?

3. Pretend like you’re designing Wikipedia’s search feature from the box at the top of every page. Using one of the personas from question 1, write a one-paragraph scenario showing a reader using the “typeahead” feature which displays likely search results in-line so you don’t have to load a separate search page. Use the scenario to highlight the problems that the implementation will need to solve.

4. Pretend like you’re designing Wikipedia’s “Watch this page” feature, which will lets editors subscribe to learn of changes to a page. Using one of the personas from question 1, write at least two one-paragraph scenarios to help your team think through the ways that people will use it. (It’s okay if you have never used this feature—​imagine how you think it should work.)

Answers

1. Reid the reader is a task-oriented reader of Wikipedia articles. Reid values the factual and unbiased information that Wikipedia provides, and prizes the transparency, particularly for political content. He wants to find and read content quickly and then move on with his day.

   Eddie the editor is a historian who creates Wikipedia articles in his area of expertise and also reviews others’ content. He feels like a steward of the content, so he keeps up with changes that others make to his pages to make sure the content and citations are correct. He wants to feel part of a community, so the health, inclusiveness, and reputability of his collaborators makes all the difference to Eddie.

2. This feature would have value, but Wikipedia’s primary goal for its main article pages should be to serve the Reid persona, since Reids outnumber Eddies by three orders of magnitude. Reid likes quick page loads, which inline editing would likely make challenging. And, he doesn’t want his random keystrokes to start editing the page. Eddie, meanwhile, is a fairly dedicated persona who will not be put off by a touch of extra friction.

3. In this scenario, I chose to highlight search ranking, spelling corrections, and the case when none of the typeahead results contained what the reader was looking for.

   Reid wants to find out who wrote Paradise Lost. He clicks into the search box and types “Paradice Lost"--he doesn’t know how to spell it—​and notices the top result is “Paradise Lost. Epic Poem by John Milton” with a thumbnail of the cover art. He sees a few other disambiguations—​like, apparently, a British gothic metal band—​but the top one was correct as the links were ranked by popularity. Had he instead wanted to know the metal band’s seventh album, he could have clicked on a magnifying glass at the bottom with the caption “search for pages containing paradice lost"

4. I’ve written a few scenarios that illustrate a product that, in some ways, works better than Wikipedia’s actual feature works. Your story may diverge wildly; the important thing is that you got into the protagonist’s motivations and addressed detailed pain points. Personally, I touched on ease of viewing edits, unsubscribing, or notification channels. You might instead have looked at how your user would get in touch with somebody whose edit they disagreed with. If you don’t like one of my design choices, awesome! Stories like this are great fodder for getting picked apart.

   Eddie has heavily edited a page on the architecture of ancient Mesopotamia and is feeling a bit nervous about its reception. He wants to see if anybody else edits the paragraphs he’s added. He clicks “Watch this page” checkbox in the editing form next to the “Submit” button, then clicks submit. He later adds a few more edits. Now, the checkbox is already checked, and he leaves it that way.

   Later, Eddie finds an email in his inbox telling him of some changes. The email clarifies that the changes are not to any of the sections he’s edited, so he ignores it. But then a few days later, somebody actually edits his section and he gets another email. He clicks into the link in the email and finds himself at a side-by-side comparison of the “before” and “after” which jumps to and highlights the change. He sees that the change simply rewords some of his text for clarity, and he’s happy. After a few months, Eddie feels like all of the emails are for edits he doesn’t care about—​it’s a long page. So he clicks “Change or unsubscribe to notifications for this page” at the bottom of the email. The page offers him a couple checkboxes he had never noticed. He can uncheck “receive notifications for sections I didn’t edit” and also “receive notifications for minor edits.” He realizes that he would gladly stay subscribed to changes to just his sections, so he unchecks the first box.