Building teams or products—the underlying need is always to solve for a challenge. Framing processes to simplify an action and trusting on techniques to arrive at a solution are usually the hacks for any team and the product they’re shipping. It all goes well only until we blur the lines that keep the actions, purpose, and solutions at their boundaries. Before we realize, we make a hodgepodge and end up yarning our complicated thread bundles. 

But, a two-question approach can help bring some clarity especially in understanding what purpose the product stands for, what actions get performed by the users, and which solutions to focus on. 

What am I doing?

This question is a primer that helps in understanding the root cause of something we plan to do. It comes handy when we (and eventually our users) mistake actions for purpose. 

After coming to the bill counter, the person does what’s shown above in the picture. What is the person doing? Simple—they’re swiping a card. If you were thinking that, you’re right, but what did you also miss? You missed the core purpose because you got trapped at the interface. ‘What gets done’ translates to the task at hand, something the interface aids in doing. The minute we confuse actions for purpose, the direction of our product stagnates. What’s actually getting done here is a purchase or exchange of money for something, and the action that aids the purpose is swiping of a credit card.

So, what really do your users do in the product? When you think at an interface level, you stop at ‘my user clicks this button,’ ‘my user skipped this step’ and ‘my user created a new entry.’ What you need to know is whether the user is one step closer to the purpose of what you built the product for. When actions become the purpose, you don’t see the potential of what you’re building for. 

So, when I ask myself “What am I doing” or when I imagine “What my user is doing” I get to the root-cause of this analysis—we’re both either one action away from or closer to the product’s purpose. 

There’s another case where we mistake actions for solutions. As product teams, we often see an incident or action at its face-value and immediately try to act against it for bringing the solution. But what if the solution lies deeper? Jeff Lawson follows a concept called ‘blameless postmortem’ that lets him and his team at Twilio get to the root cause of a challenge at hand in a conducive environment that believes such confusion is inevitable. When Uber, a customer of Twilio, reduced their spending on the services, Twilio’s stock prices crashed and their investor meetup went bad. At a first glance, all of this may seem because of their customer Uber’s decision. But a closer ‘what am I doing’ helped them understand that the root cause of the problem was that Twilio had only a handful of customers, Uber included, paying such large prices [low customer concentration] and that was because they didn’t have enough sales reps to close more deals. 

What am I not doing?

Yes, the next question is just a counter to the previous one. However, when viewed in the right sense, it helps us find the avenues we’ve not explored. Just as how opposite thinking helps in validating what we’re building is essential or not, thinking around what we’ve not done so far lets us:

—> think of new ways to solve the same problem 

[Netflix’s streaming over Blockbuster’s rental technique, Klarna’s buy-now-pay-later shopping, Fast’s single click checkout]

—> extend offerings as a part of existing services 

[Canva’s tie-up with printing services that lets you design and get those designs delivered in print]

—> find lateral personas to fill in market gaps 

[Stripe’s focus on economic infrastructure as a whole, addressing everything for a business from idea to legal setup, payment, and operations.]

—> introduce a new behavior or cult

[Snapchat stories, Honk messages, Dispo rolls, Clubhouse rooms]

This question is just a start—what follows after that is a systemic approach and root-cause analysis in different stages to finally achieve the goals. 

The same ‘what am I not doing’ helped Ben Horowitz’s then company Opsware realize that they weren’t automating their network, which deprived them of an opportunity of widening their addressable market. What started as a brainstorming in a staff meeting led them to further analyze internal resource limits for building, decide on acquisition, choose between plausible options, and finally strike a deal with Cisco to resell Opsware, which eventually payed Ben’s company $30 million, covering 90% of their acquisition costs. Good, right?

While ‘what am I not doing’ helps validate and define purpose and possible action-items for teams and products, ‘what am I doing’ helps in actions, purpose, and solutions to maintain their boundaries so there’s a clear direction for both us and our users.