To ensure our team does not create 'faster horses'

There is a famous story about the automotive king, Henry Ford. "If I had asked customers what they wanted, they would have said 'faster horses.'" This highlights the insight that we need to penetrate the true need hidden in the users' words, which is the essence of wanting to 'move faster.'

But think about it. What if Henry Ford had simply instructed his employees, "Since customers want it, let’s make the fastest horse in the world!"? His employees would probably have stayed up all night developing the lightest horse saddle and the sturdiest horseshoes. Everyone would have worked very hard. However, the result would never have been a car.

Does this story sound like something from a hundred years ago? I believe it represents the reality we face daily in our meeting rooms and on Jira. In fact, most of the products we create are indeed closer to faster horses than actual cars. We clearly set out to create a car that would change the world, so why do our results often end up being just faster horses? How can we ensure our team produces a car instead of a faster horse?

1. The fundamental goal of a project can be easily broken down.

Every project starts with a great vision. However, if we do not pay close attention, that vision often gets fragmented in the process of being operationalized, losing its original meaning.

Step 1 (Vision): "Our goal is to revolutionize the 'online shopping experience' for customers!" (A great beginning)

Step 2 (Epic): "To achieve this, let's create an 'AI-based personalized recommendation' feature." (Specification)

Step 3 (User Story): "Users can see products they will like on the main screen based on their past purchase data." (Refinement)

Step 4 (Jira Ticket): "Develop main banner carousel UI component," "Integrate recommendation product API," "Improve image loading speed"... (Complete fragmentation)

The fundamental goal fades away, and we become focused solely on the tasks in front of us. Source: Generated by Gemini

This process is essential for efficiently distributing work. The problem arises when, at the final stage, there is no 'revolutionizing the shopping experience' fundamental goal in the hands of developers and designers, only fragments of functions like 'carousel UI component development.' Those who have tasks at hand find it difficult to think about the fundamental goal while working. They focus solely on perfectly completing the ticket in front of them. Once the fundamental goal is fragmented this way, the effort our team put in often ends up in completely the wrong place.

2. Signals observable in a team where fundamental goals have been fragmented

Signs that our team's fundamental goal is disappearing are more evident than you might think. Does your team also experience these symptoms?

Symptom 1. The prevalence of zombie features Nobody can clearly explain why something needs to be created, but as long as there are tickets registered in Jira, the number of features being created increases. When asked in meetings, "Why are we making this?" the response often is "We decided to make it in the first place."

Symptom 2. Prolonged debates over trivial design issues Debates like "Should this button be blue or red?" go on endlessly. No one raises the fundamental question, "Which color would help us achieve our goal?" instead of focusing on arbitrary preferences.

Symptom 3. Meaningless worship of speed Statements like "We closed 50 tickets in this sprint!" replace the question of 'how much value did we create (Outcome)' with 'how much work did we do (Output)'. The team runs hard, but no one cares about whether the direction is correct.

No matter how hard we work, if we are creating faster horses, it is all for nothing.

I believe that if any team exhibits these symptoms, it is likely that the product they are creating is a faster horse rather than a car. To be honest, it would be fortunate if it were just a faster horse. In many cases, it can turn out to be a horse running sideways, something curious or surprising, but ultimately useless.

3. What our team must do: Attach a ‘fundamental goal’ to everything.

How can we break this cycle of tragic repetition? We can start with a surprisingly simple rule: Make sure that every Jira ticket and every operational directive, such as Figma design frames, indicates how it contributes to a higher goal (OKR, Epic, etc.).

In fact, I believe this is where the role of the planner is necessary. A planner should not just organize and throw out requirements; they should consistently remind everyone of this fundamental goal. When a developer figures out what they need to do based on the plan, before typing a single line of code, they should be able to think about the higher goal and understand, "Ah, what I am about to create, this small button, is ultimately for 'revolutionizing the customer shopping experience.'"

When this fundamental goal is alive, developers can suggest better technical alternatives, and designers can present proposals that align better with the goals. Ultimately, the fundamental goal of the product our team is creating is the most powerful motivator that turns team members from passive components into active problem solvers.

In conclusion: A team that creates cars, not 'faster horses'

What is your team currently creating? Is it perhaps lighter saddles and sturdier horseshoes? To ensure that all the functional pieces we create come together to become an innovative product, we must infuse all our work with the spirit of the fundamental goal.

Working hard alone is not enough. We must work hard in the right direction. And the compass that points that direction is the very first sentence we used to start the project, the fundamental goal.

manyfast.io