Stop Admiring the Problem...Be a Builder

The New Management Science of Being a Builder

Jul 21, 2022

Building product is not about having a large team to manage. It is about having a small team with the right people on it.—Fred Wilson

A friend of mine told me how, after earning his undergraduate degree, took a job at a small engineering firm in Los Gatos, California, that developed ultracapacitors. When his new boss showed him to his workspace, he found it littered with maps of the greater San Francisco Bay Area.

“Sorry about the clutter,” his manager said, sweeping the maps into a recycling bin. “What are the maps for?” my friend asked.

“We had to fire the last guy because he wouldn’t stop working on his personal projects here at work,” the manager said. “These were his.” As my friend settled into his new workspace, he removed the fired employee’s nameplate and replaced it with his own. Years later, MapQuest, Paypal, Tesla, and SpaceX would make it a household name. But at the time, it was just a memorable name.

Even today, decades later, Musk reportedly spends 80 percent of his time on engineering and design.1 Think about that.

One of the most influential leaders in global business spends a minority of his time on typical “management.” His energy, skills, insights, and experience focus on “building.” Why? Because creating delightful products, services and experiences are how you compete in the digital era. This is the new management science of “being a builder.”

Thank you for reading The Digital Leader Newsletter. This post is public, so feel free to share it.

Andy Jassy’s First Amazon Shareholder Letter — Be a Builder!

The annual Amazon Shareholder letters have been a foundation of counterintuitive, forward-looking, and actionable insights and advice. This year was unique in that it was the first year that Andy Jassy penned the letter. One emphasis was on “building a culture of builders. In the letter, Andy outlines a few of the diverse problems, innovations, and future businesses Amazon is tackling. These range from workplace safety to community housing to low-orbit satellites. When Amazon says “we are a culture of builders,” they emphasize the ability to define, design, or construct a capability to create new value for a company. Everyone, at every level, is encouraged and challenged to be a builder.

Here is part of the recipe outlined2:

1/ Hire the Right Builders: We disproportionately index in hiring builders. We think of builders as people who like to invent, who look at customer experiences, dissect what doesn’t work well about them, and seek to reinvent them. We want people who keep asking why can’t it be done? We want people who like to experiment and tinker, and who realize launch is the starting line, not the finish line.
2/ Organize Builders into Teams That Are as Separable and Autonomous as Possible: It’s hard for teams to be deep in what customers care about in multiple areas. It’s also hard to spend enough time on the new initiatives when there’s resource contention with the more mature businesses; the surer bets usually win out. Single-threaded teams will know their customers’ needs better, spend all their waking work hours inventing for them, and develop context and tempo to keep iterating quickly.
3/ Give Teams the Right Tools and Permission to Move Fast: Speed is not pre-ordained. It’s a leadership choice. It has trade-offs, but you can’t wake up one day and start moving fast. It requires having the right tools to experiment and build fast (a major part of why we started AWS), allowing teams to make two-way door decisions themselves, and setting an expectation that speed matters. And, it does. Speed is disproportionally important to every business at every stage of its evolution. Those that move slower than their competitive peers fall away over time.
4/ You Need Blind Faith, But No False Hope: This is a lyric from one of my favorite Foo Fighters songs (“Congregation”). When you invent, you come up with new ideas that people will reject because they haven’t been done before (that’s where the blind faith comes in), but it’s also important to step back and make sure you have a viable plan that’ll resonate with customers (avoid false hope). We’re lucky that we have builders who challenge each other, feedback loops that give us access to customer feedback, and a product development process of working backwards from the customer where having to write a Press Release (to flesh out the customer benefits) and a Frequently Asked Questions document (to detail how we’d build it) helps us have blind faith without false hope (at least usually).
5/ Define a Minimum Loveable Product (MLP), and Be Willing to Iterate Fast: Figuring out where to draw the line for launch is one of the most difficult decisions teams must make. Often, teams wait too long, and insist on too many bells and whistles, before launching. And, they miss the first mover advantage or opportunity to build mindshare in fast-moving market segments before well-executing peers get too far ahead. The launch product must be good enough that you believe it’ll be loved from the get-go (why we call it a "Minimum Loveable Product" vs. a "Minimum Viable Product"), but in newer market segments, teams are often better off getting this MLP to customers and iterating quickly thereafter.

Amazon believes so deeply in the “power of builders” that this philosophy is the backbone for a major business — AWS.

Being the chief product officer requires certain skills, some of which may have atrophied over the years as people have advanced through the byzantine ranks of an organization. The younger versions of ourselves may have been acutely talented chief product officers. Yet as we migrated away from the real work and into the nebulous world of management, we may have lost our edge. Suddenly, as chief product officer, you are expected to write the idea, conduct the customer interviews, design the user experience, figure out the technical requirements, and rationalize the market fit requirements and target cost to produce.

You need to “be the builder.”

There are many benefits to becoming the chief product officer and dusting off your “design” toolbox. First, the project will benefit from your years of expertise. Your attention to the nitty-gritty details sets a fresh tone for the organization. Everyone needs to dive deep and understand the details from top to bottom. You can skip freely around the organization’s hierarchy. Develop personal relationships and influence team members at all levels.

Builders are people who like to invent, who look at different customer experiences and try to figure out how to reinvent them. We’re all builders because companywide, we’re all working together to help our customers grow and thrive. — Andy Jassy, Amazon CEO

For example, Musk reportedly spends half a day each week working directly in the studio with Tesla’s design guru Franz von Holzhausen. Musk remains up to his elbows in problem-solving on products. He is part of the creative process, manufacturing process, every major element of “customer experience,” and wherever the operational bottleneck might be. This is intentional. This is how great products are built, and hard problems are solved.

Stop Admiring the Problem

For many of us, the approach to “be a builder” is best encapsulated in this simple statement — “define the future state.” Complaining is not a strategy, and complaining about the “current state” or “why we can’t do something better” does not create value. I call this “admiring the problem.”

Only being able to funnel these observations into “therefore, this is (exactly) how the future state should operate” creates value by taking action and directing the team toward a specific mission. I have had clients where I have to create “penalities” for complaining leading with what’s broken about the current state. They spend most of their time creating negative energy by stating all the ways the current situation is broken. Want to create business value or solve a problem? Tell me exactly what the future state needs to be!

In “Let’s Get Real — What Is Digital Transformation”, I wrote that many digital transformations fail to deliver forecasted value because they don’t start by defining specific expressions and definitions of the future state. Instead, vague notions of the future state are made, wrapped in all the “problems and constraints of today.” This is neither helpful nor inspiring to your team.

There are many reasons why most digital transformations fail. To “transform” means to evolve and change. In the case of a business, this change needs to happen in a directed or guided manner; it needs to happen at pace, have an ROI, and create business value. Incorporating these two steps will improve the outcomes of digital transformation.
Action #1: Define the “What if…”
Build a vast catalog (25 to >100) of specific “what if …” use cases, processes, examples of prior behavior, or pain points that could be transformed. These are not just the current state (the “from”) but much more critical is the future state (the “to”).
Action #2: Rationalize
If you are at all creative in the first step of building use cases, you will have a vast (25 to >100) of potential concepts. You can’t do them all, at least not at once. Build a simple rubric for evaluating these concepts and then set a course. An example of a simple rubric might be evaluating concepts by “potential benefit” versus “potential risk.” I’d recommend having distribution in the portfolio.

The Digital Leader Newsletter -- By John Rossman

Let's Get Real -- What is Digital Transformation???

The Digital Leader Newsletter — Strategies and Techniques for Change Agents, Strategists, and Innovators…

3 years ago · 2 likes · John Rossman

Let’s Talk

Is your organization moving too slow or “admiring the problem”? Suffering from stagnant growth, decreasing margins, rising material and supply chain costs, or a lack of successful innovation? Let’s talk about improving the ratio of “building” and “builders” in your organization. (info@rossmanpartners.com)