When you're building a product, there are different frameworks you can deploy to think critically about what to build and why. These frameworks apply to business as well.
When designing a product – or launching a startup – you should answer a few fundamental questions:
- Should I enter the market or not?
- Who else exists in this market and what are these firms doing or building?
- What are the costs of entering this market? Are these costs fixed or variable in nature?
- If I decide to exit the market – or stop building or maintaining my services or software – what are the costs?
- Who will use my product or services and what do they value or need?
- Am I uniquely equipped to help these people or constituents?
This article provides an overview of four interesting, dynamic, and different approaches to probe your assumptions and answer these questions. Ultimately this article is about strategy.
Strategic thinking is about the art of outdoing an adversary knowing that they are trying to do the same to you.
Albert Einstein once asked, “If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign?” Just because a desk is empty does not mean it’s not contributing utility. For strategies to be effective they too need to be useful, applicable, and relevant.
Oftentimes building a company – or creating a piece of software – is about the application of strategy.
At a more granular level, this article attempts to help you think about the above questions by leveraging mechanisms for transforming inputs – like data, beliefs, and research – into a desired set of outputs that are easy to deploy in your everyday life and useful.
I have learned about these frameworks through a mixture of reading product launch templates, building products with my own hands, and studying how other product and business stakeholders optimize their work to drive the outcomes they desire.
I want to explain each framework and pass on the most salient takeaways from each so that you can rapidly apply these frameworks and build more effectively.
Framework #1: The Airplane Crash Test
Reginald H. Jones, the Chief Executive Officer of General Electric from 1972 to 1981, was in search of a successor upon retirement. He asked each of his executive subordinates a question:
“A plane crashes and you are on the plane. You don’t survive. Who should take over running the company or building the most important products, and why?”
This is an interesting question to ask yourself, and is especially salient as you build and scale products. Who do you know that is best suited to be the leader in an environment filled with ambiguity?
In your mind, is it you? Is it a peer? What does this person do so well that inspired you to think of them? Try to replicate their behavior and knowledge base to better equip yourself as a builder and product developer.
If you did select yourself, think about why. What skills do you have (technical, business, political, and so on) that can help you drive an organization or product forward? How will you teach those skills to others?
By thinking through the airplane crash test you can reflect holistically on what you do well, why those skills matter, and areas for improvement. You can also gain a deeper sense of appreciation for the skills that others in your life – or on your team – may have.
Framework #2: The Airport Test
This framework is very different from the airplane test. In this thought experiment, ask yourself the following: if I were to be stuck at an airport for many hours with someone, what kind of person would I want that person to be? And secondly, if others reflect on the types of people they would want to spend time with, am I one such individual?
Google famously applied an “airport test” to help conceptualize the types of people it would want to hire. On one hand, the airport test lends itself to some admirable outcomes.
If you are stuck at an airport for many hours with someone, it makes sense that you would want to surround yourself with someone who is curious, insightful, and easy to communicate with. These are valuable skills to cultivate in life, and as a builder.
On the other hand, this test has limitations – and the biggest one is seemingly bias. Would you rather spend more or less time with someone who thought and acted like you?
If so, you might be overlooking great people to learn from and spend time with that differ from yourself.
When building products at scale, you will want to think about all potential users. Many users are different from you and come from different walks of life. Think holistically about these users and who they are – their wants, needs, and diverse backgrounds – so that your product or business can best meet their needs.
Think about the airport test as bi-directional. Try to be the type of builder, motivator, or creator that others want to spend time with. Look for others that meet that test for you, too.
Framework #3: The Working Backwards Framework
Working backwards is a framework practiced by many product builders because it helps set a North Star rooted in customer feedback.
At its core, Working Backwards is a belief system that states that you should speak with users and customers and listen to feedback about what to build and why. The product designer, after organizing this feedback, can start building tools and services that users care about and want.
By working backwards, a builder can save time and money.
Amazon Founder Jeff Bezos once noted that while he can’t predict the future he can’t imagine a future in which people want slower delivery or higher priced items.
By working backwards from the fundamental needs and goals of users he can build solutions, technology, and products that empower these people.
Many great products that you leverage in your daily life are predicated on designers looking at the needs of users and building based on those inputs.
In the case of image searching technology, coders literally saw that people had an end goal of using images to run searches. Working backwards from that destination enabled the creation of reverse image search technology.
When you are building, try to place yourself in the shoes of users and go speak with them. By building relationships and starting these conversations you can be guided by what your users actually care about.
Once you know what matters, you can obsess over the details that best help you help your users. That is what the Working Backwards method is all about.
Framework #4: Jobs To Be Done
A fourth and final framework for understanding how to build businesses and products is to think about why people are “hiring” your technology and what problem your technology solves.
The late Clayton Christensen of Harvard Business School famously argued that the “customer is the wrong unit of measurement”. Instead, Christensen noted, people use solutions for “jobs to be done,” or the pain points they face in their lives.
When you are building your next piece of software, or product, or business, ask yourself: why are people hiring me to do this job? If you believe that your customers are rational, evaluate their behavior.
If you think that your rational users are making irrational choices, take time to better understand how your tool is actually being used.
By framing your work in this light you can develop and hone in on a very important skill set for builders to cultivate, and that is empathy. If you can’t empathize with how your product is being used (and for what purpose) you won’t be able to empathize with your users.
Bringing It All Together: Frameworks for Development
I have outlined four different frameworks to help you think about your work, how you devise products, and ways to conceptualize the development of your software or products across users, time, space, and markets.
These frameworks are not mine but represent interesting and influential nuggets that I have picked up watching others. These nuggets have influenced how I think about design, feedback, and content, and I hope they are useful for you too.
The application of these frameworks can help you build.
You can apply all, some, or none of the above. However, my hope is that by thinking about these questions and approaches you can dive deeper into solving real problems for real users and that you can better develop the skills, product design mindset, and empathy to align your products with the needs of your current or future users.