A strategy is a plan to win. When a basketball coach puts a strategy, they have a plan to win the game. Professional gamers also put a strategy to win the game. A product team needs a strategy to win.

Win what exactly? To win whatever you need to accomplish in this moment. Usually, the company has a mission, and your role as a product team is to determine the steps to progress on that mission.

Being strategic starts early in your career as a product designer. At first, you will support this strategy. That means you need to understand what’s the strategy. As you grow into a more senior role, you’d be expected to establish the strategy. Either way, having this strategic mindset is critical.

Tesla has a mission to accelerate the world’s transition to sustainable energy. But how? The how to win is the strategy. Their strategy is to build a sports car, then use that money to build an affordable car, and then use it to build an even more affordable car. You can read Elon’s note. https://www.tesla.com/blog/master-plan-part-deux

No matter what’s your role, having a strategic mindset is critical. In this article, let’s discuss four steps to understand or structure a strategy.

4 steps to think about a strategy

If you’re not involved in defining the strategy, you will need to understand the strategy to make informed decisions. If you’re responsible for crafting the strategy and solving the problem, structuring your thinking will be crucial. Either way, here are four steps to understand a strategy:

Step 1: What is the current situation?

This is the current situation you’re dealing with as a team. Maybe you realize your users are not adopting the new feature you’re launching. Usually, it’s the symptom.

Step 2: What is the complication?

Then, understand what’s the effect of that situation. If we don’t solve this, then what? If no one is aware of our feature, then we can’t deliver value to users, and we can’t increase retention. There are two layers here: (1) Understand the complication for the users and (2) get a sense of the effect on our internal team (metrics, monetization, morale, and so on)

Read more

The students who asked this question were understandably frustrated because their team kept cutting the design, and they ended up with an “ugly” product.

Make your product useful. What I mean is to solve critical problems so people want to use and pay for our product. Why? Because no matter how great the interaction design in your product is, people won’t adopt it if they don’t find it useful.

At this point, it doesn’t mean that you ignore usability. Instead, you want to prioritize the “useful” part, and you should sacrifice the "usable" and "delightful" part. In other words, you must sacrifice some ideal interaction to move fast. It's all about prioritization. You may ask then, how much of the interaction should we sacrifice?

Each product category has a different baseline for its usability. For example, if we’re building a chat app today, users will expect they can send an emoji

Read more

Read more

Who is it for?
If you’re creating a bag or any product, the first question you must answer is, who is that bag for? Is it for teenagers who want to look stylish? Or is it for lawyers who need to bring lots of documents? Different answers lead to different types of bags you will design.

1.

It’s easy to fall into the “for everyone” trap. We fall into this trap because we know that almost everyone uses technology and the internet. Then, we become vague about who it is for.

If we say our feature is for teachers or drivers. That’s a very broad definition of users. The “for everyone” mindset leads you to build features that try to solve everyone’s problem and ends up not solving anyone’s problem. You will talk to all customers and realize they have different problems. Then, you get confused about which problem is the most important one.

2.

Not everyone. No. Facebook started with connecting college students. Twitter started with group SMS. We must narrow down our target audience.

We start with our intuition—a qualitative hypothesis of who it is for. Here are a few attributes you can narrow the target audience:

Read more

1. You are building a feature, but what is it for?

We know that recognizing our intuition is an essential part of building features. But intuition is often abstract and hard for our team to understand. The next obvious question is: How can we turn this abstract intuition into something concrete?

I like to use a feature strategy framework. When you develop a feature strategy, you can look at these three components:

The paid subscribers can access this full post and get the template

Read more

I don't like writing about myself. But after I shared my decision to quit my job and the idea of a value audit exercise, a few people asked me. They were curious about the output of my value audit exercise.

I'll share 10 notes to walk you through my thinking about some of the values, so you can get an idea of how exactly I arrived at them. I'll also share some resources you can use for this exercise. Here:

Growth

• Am I learning and expanding my knowledge? Curiosity

Read more

This post at a glance:

• Standford study about design exploration

• How design exploration can benefit us?

• The process to come up with many alternatives in a reasonable time 🔒

• How to utilize inspiration methodically 🔒

Q: How can I come up with different alternatives, so my team can discuss and make better decisions?

I spent my career as a Product Designer and recently moved to Product Manager. Now, I love it when the designers bring lots of alternatives to the design review session. It’s helpful. The discussion becomes more productive.

I also found this interesting study from Standford about design exploration.

Serial vs. parallel group

In 2010, researchers at Stanford University did a study with 33 novice designers. They want to know the most effective way to explore and iterate the design work. The designers were divided into two groups to create a banner for online advertising with a different process.

The first group was the serial group. Designers in this group have to make one design at a time. Then, they will receive a critique from an expert each time they have one design (they repeat this five times), then make a final revision.

The second group was the parallel group. Designers in this group have to create three designer alternatives instead of one in the beginning. Then, the expert will give a critique of those three altogether. After that, they will create two more explorations and get one more piece of feedback before making the final version.

Finally, everyone uploaded their work for a 15-day campaign. The researcher analyzed the performance based on the number of clicks.

The result?

The researchers noticed the top-performing banner were both from the parallel group. The researchers were also discussed the result with the experts and noticed he work from the parallel group was more diverse and had a higher quality.

Benefits of diverse explorations

First, when you have multiple ideas, you can compare and analyze them side-by-side. You’re motivated to explore and reach a more optimal solution.

Second, when you discuss multiple concepts, your team can say, "This one works. That one doesn't." You can compare and contrast. It results in a more productive discussion.

Finally, when you have multiple alternatives, the discussion focuses to find the best option. It’s not about judging you. You can detach yourself from your work, and engage more with the feedback.

The question: How can we make good exploration within a reasonable timeline?

I want to share a workflow I’ve established over the years. Adjust according to your context. The process looks like this:

Read more

Here’s a question from the reader who read the onboarding design principles:

Q: Hi Budi. First of all, I really love your newsletter. I get a lot of value out of it. I read your article about onboarding design principles and I find it interesting. Can you share how to apply that principle in real work? My team will work on the onboarding project, but it’s still vague. How can we measure success?

Thanks for the question. In this post, let’s discuss how you can implement it. I’ll share the frameworks and templates to help you put the idea into action.

Budi

Many designers and product managers think about onboarding as the onboarding pages or coach marks. But, it’s not a holistic approach.

When designing an onboarding experience, we can think of two moments: 1) the setup moment and 2) the valuable moment.

Subscribe now

1. Define your valuable moment & core action

Good onboarding design is about minimizing the setup time so that the new users can feel the core value of your product sooner. It’s the moment where users feel, “Oh, this product is actually useful.” Tweet this

Let’s go through a few examples.

Uber: If I want to go to the office from my home, then the valuable moment is when I arrive at my destination. The core action is when I click Order Ride.

Bank app: If I want to transfer money to my friend, then the valuable moment is when my friend receives the money. The core action is when I click Send Money.

Thinking this way helps your team to think holistically. Your onboarding project is successful when you can help more people receive value from the product.

Exercise:

• What’s the valuable moment in your product?

• What’s the latest action in your product that indicates the users are going to get to the valuable moment?

2. Define the setup experience

Then you can think: what would it take for the users to get to that valuable moment? This will help you define the setup experience to evaluate it later.

Read more

Your team needs a continuous research cycle. You can't just conduct a research initiative, create a persona, and call it done. Instead, the research practice has to be continuous and rapid. I'll write another article for this next week. It’s better to build the persona slowly as you go.

1/ Build a plan. Articulate your hypothesis and be explicit about what "decision" you would make if you got the insight.

The research's goal is not to build the persona
The research's goal is to help you make a decision
Persona is only a tool to document the insights you get

2/ Conduct. The next obvious step is, of course, to conduct the study. To listen. To observe. Pay attention to biases. When observing, I like to write down the verbatim—word by word. While also paying attention to the nuances—what's the meaning behind the world users verbalizing considering the context?

3/ Have a quick debrief. It's essential to have a quick debrief after your team the moderated session. In my team, I use Miro and synthesize it with this format:

• About (What is interesting about this user)

• Goal (What is their goal)

• Motivation (Why they want to reach the goal)

• Frustration

• Workaround

4/ Have a big debrief. Once you finished the whole session. Debrief, again. What makes this session different from the quick debrief is that now you have talked to a few users. It’s time to find the pattern, watch out for outliers, and connect the dots. Basically, you want to finalize the analysis of the qualitative insights you get.

5/ Document the insight. You can use many frameworks to document the insight. The persona format is useful to capture insights into the different archetypes of users. Just use a simple doc or slide. Keep it lightweight. No need to put it in a fancy format (like the one you can find on Google with pictures and sliders 🤣 )

P.S. Paid subscribers can access the simple persona template and additional tips by the end of this article to put your learning into action. Also, you'll get a few inspirations.

Subscribe now

Related posts

• Decision-first approach: An approach to create actionable insights (with template)

• Trust battery

• Dear Budi: What cadences do you run in your team?

• Make your 30 days onboarding plan

• How to prepare your one-on-one as an individual contributor

• About designing onboarding experience

Subscribe to join 1600+ practitioners—this newsletter is for people who want to build impactful products and solve hard problems.

Share

Read more

I heard that argument a lot. But is it?

Hi friends,

Early in my career, I used to think persona was useless. But I have a different view of it now. Especially after I transitioned as a product manager, I realize how important it is to prioritize who is your target audience.

I encourage a product manager or designer to build one. Persona is helpful because we always have limited time and resources to build a product. Here are a few notes to consider why persona can be beneficial:

1 - Persona helps your team to prioritize who to serve. (Tweet this) Did you know that Facebook started with a small audience—Harvard students? Tesla built their first car targeting the high-end market first because that makes sense for their business model. So, when building a product, you gotta focus on a specific segment first, and the persona helps you answer, okay from this various persona, who should we focus on?

2 - Persona should be lightweight and easy to maintain. (Tweet this) Just a bullet list, look how Gitlab and Office for National Statistics manifested their insight. You don't need a photo, no bar chart that's not helping you make the decision. Keep it simple.

3 - A bullshit persona is not the same as an insight-based persona. (Tweet this) Persona is simply an interpretation of reality. So, writing down the information based on your team's assumptions is not helpful. I prefer to use a persona as a tool to synthesize insights and understanding of the user.

4 - A lot of designers put a persona in their portfolio for no reason. (Tweet this) A lot of people grow resentful with persona because they see a lot of portfolios including a persona because the designer wants to ensure they apply “Design Thinking.” Yet, when they ask the designer how they use it, the designer can’t answer it properly. However, that doesn’t mean a persona is bad.

Read more

One-on-one is so important that entrepreneur Ben Horowitz was willing to fire a senior leader for not having regular one-on-one meetings, which he shared in his book The Hard Things about hard things.

Here’s how I run mine so far to manage up:

1. Usually, it’s about 30-50 minutes. I scheduled it weekly or bi-weekly.

   I use it for a few things: Give highlights on the progress, discussions, sharing feedback, and what’s next.

2. I like to start with a general pulse check, “How’s your week so far?” and get a sense of the general mood. I also share mine.

3. A quick highlight about last week. For example last week our team did a few interviews and decided we want to focus on the onboarding phase first. Then I explain a few rationales behind it. I keep this one light and quick—under 10 minutes.

4. I then go on and discuss a few discussion points. This can be anything from career discussions, any blockers that I need support for, or any challenges I need to brainstorm with my manager. This will be the main topic.

5. Feedback sharing is always part of the routine. In my first session, I build an expectation that we can use this session to share feedback. This is a culture that I set recently with people who work closely with me, so we know we both know we can exchange feedback in this session.

6. Before we wrap up, I share my focus for next week. This is a way to ensure the manager understands how I think and what is my priority. It offers a chance for them to challenge me if they think my priority is off.

7. I write all of the next steps and decisions. Writing it down is easier. Research shows that sharing the next steps helps ensure they get done. Make sure to put that into the next one-on-one agenda as a discussion point.

Resources & template

Here are a few resources:

• 101 questions to ask in one-on-one

• 74 questions to ask in one on one with a manager

• The update, the vent, and the disaster

Paid subscribers can download the template:

Read more

We discussed how to scope product design work in the previous post. It’s a critical process a lot of designers skip. As a result, they often realize they haven’t thought of the edge cases later in the project. Here are a few important principles you could consider while scoping your product design work.

1) Always focus on the problem first. Scoping is about breaking down different user interactions. Do a problem rundown exercise first to sharpen the problem before you scoping. If the problem is unclear, your scope will more likely change.

Read more

Seems like you work in a modern product team often timebox their work. Which is awesome. Timeboxing prevents us from spending 3-6 months building something no one wants. The faster we ship the product to the customer’s hand, the sooner we get real-world signals from users.

Identifying the potential work upfronts can really help you in that environment.

When I was an individual contributor, I never get a practical advice about scoping. So I build my own process, which I’m gonna share with you.

Let’s imagine you only have two weeks to improve an existing feature. What can you get done? Which part of user interaction should you cover now, and which one can be ignored now?

That’s a tricky question. But an important one to answer.

How to break down the design scope

In this post, we’ll go through the step-by-step scoping process. We’ll use a hypothetical example from Uber to make this guide easy to follow. Paid subscribers can access the template.

Subscribe now

1. Identify the users and their goals

To start, you want to identify who the users and what their goal is. If you still aren’t sure, you can use a simple problem rundown template:

Our users are _____(users)___
Their goal is ____(job to be done)____
Their struggles are ____(pain points)____
We know this true because ____(data / observation)____
Solving this will be great for our users because ________
and also benefit our organization because ________

Let’s use Uber as an example. Imagine that users still need to pay their Uber trip with cash. We want to provide a way for users to add a credit card as the payment method. The problem rundown could look like this:

Read more