What is the difference between a great idea and a great product?

Execution.

When we execute on our ideas, we start building towards a product.

How can we do well on our idea and make the most out of it?

Ruthless execution.

Ruthless execution is the fertilizer for product managers and any start ups who embark on an entrepreneurial journey.

“Ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions”

Steve Jobs

There are three ingredients you need for ruthless execution — Strategy, agility, and culture.

Strategy describes the (unique) advantages for a product and lays out the blueprint required to succeed. The strategy could be to bake bread that is crispier than others.

The agile methodology is a way to drive clarity of outcomes & efficiency for tasks and is a way for empowered teams to quickly iterate. Agile iterations mean building & finetuning, to eventually have a machine that bakes crispy bread.

Culture is what makes the machine work, prescribing ways of working. Staying in our bread metaphor, Culture is the electricity & oil, it’s what makes the machine ruthless (or a failure).

Let’s break them down.

Strategy — Define your unique advantages to be executed

The first ingredient for ruthless execution is strategy — it gives teams a north star to aim for.

“Strategy defines the company’s distinctive approach to competing and the competitive advantages on which it will be based. A good competitive strategy is one that creates unique value for a particular set of customers”

Strategy definition from the Harvard Business School.

Good strategy makes your idea accessible, and your team intuitively understand the rationale on why they work on specific tasks.

Bad strategy is the opposite — it’s an abstract mess. ‘Solving world hunger’ is an honorable strategy that your developer won’t be able to execute on. The big picture should instead be used as your vision, reflecting on what is the purpose, why your product needs to exist.

A shared understanding of the “why” is essential for efficient execution. For as long as someone does not understand the strategy, he/she will take decision to solve a task that are sub-optimal.

Vision is the initial thought about what kind of place it will be and why it will matter. Strategy is the blueprint for the foundation and framing.

Imagine you tell someone to build wheels for your car that are 30% more resistant. Your scientist makes the wheel size slightly heavier, which gives even 50% more resistance. Great! But if your strategy to have superior energy efficiency, the heavier wheel now cost more energy & you are hurting your desired advantage.

Specifically with technical teams, smaller tasks quickly can become over-engineered. At fault is the product manager, not the developer.

If the importance of a given task is unknown, team members are not able to prioritize nor work the most efficient solution, but rather strive for the most sophisticated.

A roadmap is a great way of visualizing strategy & making it accessible. My favorite way of plotting a roadmap is the cupcake, birthday cake, wedding cake methodology, which is rooted in design thinking.

Here is an illustrative example how this concept could look like in practice.

Here is how you would put the above together:

Think about what is your USPs and strategy. Research & discovery, primarily via user engagements will help you determine how that would look like. Your strategy gives you two things:

First the dimensions that are relevant to your product (e.g. for Airbnb it could be hosts, travelers and the app itself). Ideally those categories are MECE (ME = Mutually Exclusive = there is no overlap and CE = Collectively Exhaustive = it lists ALL that you need to do). Generic concepts to start with are Front end, back end & user or people, process & tools.

Second, strategy gives you the input for wedding cake & each dimension. In our example, Airbnb strategies for hosts could be to have a ‘Self-serve platform for hosts to upload, maintain & optimize listings’.

Once you have dimensions & strategy set, work your way backwards to the cupcake.

What is the least resource intensive way to get to a testable version? For our host dimension, you really want to have a host to begin with. Brainstorming gives you the to do’s you can start with to eventually reach a desired milestone (like number of hosts signed up).

Lastly, the birthday cake is the intermediate step between cupcake & wedding cake. It describes the steps that are required to scale the cup cake approach.

The main reason I am a big fan of this framework, is that it creates team alignment.

Having the strategy laid out clearly makes it easy for team to stay aligned to the core of a product. It’s now intuitive for teams to not over engineer specific tasks (like not building a UI for admins to enter listings since that is not the strategy). The strategy is to have hosts (not admins) to maintain listings, clarifying things that need to be built to last.

Understanding the strategy empowers team members to take the best (not sub-optimal) decisions for the product.

Alongside, it also helps to gives an insight how success looks like and lays out the different stakeholders.

One comment on timeline and why there is an arrow between milestones / OKRs and strategy. The idea behind the cakes is to think in timeboxed three different phases. Maybe your cupcake is just a two-week sprint and quarterly OKRs is your birthday cake. The timeline will vary depending on team productivity & product maturity.

While strategy describes you action plan on a ‘macro level’, running your team on agile would be the ‘micro’ level, or ‘how’ to tackle task from the action plan.

Agile — execute on your unique advantages

Agile delivery is an execution methodology aiming to accelerate development.

We’ll review the premise of agile in theory before taking a look how it’s implemented in practice.

Agile, the unlock to accelerate development

Agile is based on three core objectives:

1. Remove slack by driving clarity of outcomes,

2. simplify the decision-making process through self-directed teams

3. and user validation to enable quick iterations

Let’s dig into one by one.

Clarity of outcomes allows team to focus on developments needed, not possible. Outcome oriented execution keeps slack to a minimum.

The north star here is user value. In essence, if I can attribute every piece of development (be it UI, backend, workflow, marketing, etc) to a business outcome, I am able to prioritize perfectly. In theory, what gives the biggest increase in value, should come first and will be released under agile as soon as it is ready.

This stands in contrast to traditional, waterfall driven, project management. Here, a release date is set months in advance and teams bundle together what can be done it that period of time. But the user can’t enjoy any value until the release date.

This changes team perspective, the focus of development teams is not the project timeline, under agile it’s user value.

A focus on timeline invites teams to take sub-optimal decisions. From my experience, it’s usually an over-ambitious timeline leading to teams not building enough slack on high value features.

If the focus is user value, teams will optimize to build no slack — not too little (untapped user value), not too much (known redundancy).

The second objective is self-directed team.

If every decision must be signed off by a boss or stakeholder, development speed slows down. The team spends their time educating & pitching, rather than developing. Your product is not getting better, it’s getting explained within your company.

Note that there is an order to the objectives. Without clarity of outcome, teams will build something off-course. Imagine your New York team has been given the desired outcome to go west. Some will go to Mexico, others to Canada, but if you want them to go to California, that needs to be clear.

This aspect makes management hesitant to let loose. They don’t trust their teams to build the right things. Somewhat ironically, the manager, who wants to accelerate, then becomes the bottleneck himself. A slippery slope.

“If words of command are not clear and distinct, if orders are not thoroughly understood, then the general is to blame. But, if orders are clear and the soldiers nevertheless disobey, then it is the fault of their officers.”

Sun Tzu — The art of war

As a manager that wants self-directed teams, you need to empower you team.

What’s underestimated is how difficult it is to empower teams. It’s not simply letting loose and a manager saying “do what you want”.

I believe, it boils down to if your team can distinguish output (I build X) from outcome (building X will increase Y user value).

If they can: Decentral lies the expertise. A developer will come up with a better architecture than a manager. A UX expert will create a better design than a manager. And the list goes on.

Empowering teams is a longer process that requires multi-domain workshops, collaborations, discussions and more. As mentioned above, transparent strategy and a team capable (skilled & motivated) of evaluating outcomes, is required to make your team work.

Lastly, agile is associated with quick iterations. Not just because of the move away from waterfall releases, but also by giving user validation are a more prominent role.

This is the key differentiator from other methodologies. Once teams understand outcomes & are empowered to take decisions, user validation is how self-directed teams learn & iterate.

If I am a developer, in traditional project management I am given a backlog of tasks and work my way down. Moving to agile, understanding the outcomes & taking decisions based on my expertise, finds arguably ‘better’ decisions. Then user validation is my learning process required to iterate.

User validation is the unlock to accelerate quicker. In agile, the doer is the expert and takes decisions based on user value. That’s the flywheel. No need to communicate learnings upwards and/or risk getting insights lost in translation. No need to wait for prioritization.

The doer knows what’s best. Thanks to clarity of outcome, the ability to take decisions as part of a self-directed team and uses user validation to learn & drive quick iterations.

So how can this be implemented?

Agile in practice

In agile, work is managed through a tracking board, usually from Jira, Zenhub, Trello or related.

While each tool has their nuances, the core concept of tacking work is the same.

Each work effort is described on a card. Each card should contribute to a strategic objective (‘Epic’, OKR, …), which is a simple test to check for outcome vs output.

From the teams I’ve worked in, the way cards are written drastically differs. Some like it simple (which works in a high trust & high performance culture), some more descriptive (better support for junior talent).

Each card is a one pager that has several elements:

• Title: Intuitive, so when a team says I am working on X, everyone knows what is being talked about.
• Owner: Who bears the responsibility? Ideally this person also writes the card
• Problem statement: Why are we doing this? Essential to establish a connection to user value
• Description: What needs to be done? Ideally this is written from the perspective of a user.
• Checklist: What steps get us to desired outcome? Good if this flags dependencies.
• Definition of done: When do we know we have done our work & can ‘close’ the card?
• Success metric: How will we (eventually) track success?

Example card for a new hypothetical feature for a grocery delivery app

• Title: Cooking recipes inspirations
• Owner: Felix / User Experience
• Problem: When a user wants to prep a certain dish, the app makes it time consuming to navigate too all required ingredients and they have to toggle between our app & their recipe.
• Description: As a user (persona), I want to get inspired to cook a certain dish & an app that does the shopping for me, so that I save time when planning meals. Users see on their home page a bar with recipe recommendations. When the users clicks on a recipe, the users then can read the recipe, select the expected guests & the app will add all appropriate ingredients in the shopping basket.
• Checklist: Add sample recipes to database; Map recipes ingredients to units; Enable recipe bar in the homepage; Create new UI for recipe details; Create logic for adding list of ingredients to shopping cart; Test UI with x test users; Deploy changes
• Definition of done: X number of cooking recipes inspiration live in production
• Success metric: Users that engaged with recipe inspirations show higher A) user retention & B) average shopping cart size

Cards are the center piece of the agile methodology as it basically is the main channel of team management.

Team management is done via different sessions, called ‘ceremonies’.

Given that the intention is to accelerate development, you don’t want to commit to anything you don’t know. Hence, agile is done in sprints, commonly two weeks. Every two weeks, the clock resets. Teams can adjust course to their new learnings.

Each sprint has the following ceremonies:

• 1. Sprint planning: Create tasks for each member (first Monday of the sprint)
• 2. Standup: Updates on task & discuss on intersections (daily)
• 3. Backlog refinement: Review progress & adjust tasks (second Monday of sprint)
• 4. Playback: Showcase progress (last day of sprint)
• 5. Retrospective: Update ways of working (last day of sprint)

In the first ceremony, sprint planning, the team finalizes & agrees on what gets worked on for this sprint. It’s usually on the first day of the iteration. Practitioners prepared their cards to the best of their ability prior to the discussion.

You might ask — each card looks quite detailed and requires oversight into more than just domain. How can the owner know all the right things to build, inside and outside their domain?

Sprint planning itself is a session, that can run anywhere from 30 minutes to three hours, where teams can have a collaborative discussion. Each card is reviewed one after another, sometimes jumping back & forth, editing the contents on each card.

Ultimately, the sessions’ objective is to agree on the steps to be build and how they are build. It’s the product manager’s role (depending on the version of agile, also called iteration manager or scrum master), to hold the team accountable. Required is from each practitioner to A) create cards in line with the set requirements, B) check prioritization (as it’s the person with the most oversight) and C) make sure everyone has just enough on their plate (ensuring maximum productivity).

Next up is the daily standup.

The intent here is to keep your team in the loop on each other progress as well as to catch blockers early.

Since the task checklist is not always isolated to the owner, it is common to have overlaps into other departments. Following the recipe inspiration feature example above, the Product Manager might provide you with the recipes. Or a back-end developer might create the shopping cart logic.

Raising awareness when a task is ready to tackle, reduces idle time. If I am a backend developer hears that the recipes come two days later than expected, he or she can adjust his or her schedule.

Daily standups can happen any day of the sprint. The main updates from each role should be super crisp, so that the team can get in & out in 10 minutes. If there is something that needs more explanation or a general adjustment, there could be additional deep dives. Those are somewhat extension on issues raised through the standup & could be customer or tech deep dives.

Halfway through the sprint is the backlog refinement. It’s a slimmer version of the sprint planning, allowing the team to make changes as things changed. Maybe the initial user reaction prompts a change in UI and therefore requirements. Or a high priority ad hoc request needs to be handled first.

The most benefit in my opinion comes from “yes, and” moments. In those moments, owners can say

As each owner work on their respective task, they identify further valuable features (= ‘yes, and’ moment). This could be a theme that came out of user validation (for instance, they might like the recipe inspiration, but they also want to get recipe recommendations). It could also be technical nature, for instance today we are pulling data via this workflow, but we could also do it this in the following improved way.

The backlog can quickly become a trash landfill. It can bloat up, making it difficult to navigate or prioritize. It’s up to the Product Manager to identify themes, merging relevant topics, and removing out of date redundancies.

On the last day of a sprint, there a two more sessions, the playback and the retrospective.

The playback is a showcase of the team’s work. Each member gets a fixed time slot to do a show & tell. The keep the session focused, the Product Manager needs to set a format how each member presents their progress.

The playback is a driver of motivation, as it gives each contributor the stage to receive recognition for their work. If presented well, other team members are much more likely to engage and more likely to provide constructive feedback.

Also, it serves as inspiration for the next sprint, as it demonstrates where more work should be done or additional ideas that were generated.

Lastly, it’s a great communication channel to stakeholders, especially internal leadership. It’s likely the most intuitive demonstration of progress. It’s the only ceremony where I would advise to add non-product teams and/or leadership.

The retrospective can be the last session of the week and tackles the ways of working.

What does the team feel were detractors? What was helpful?

This ensures to continuously drive team efficiencies. The session can be done via sticky notes or virtual emulators like mural or miro.

If team don’t feel they can be open, this session is a waste of time. It all about calling out deficiencies. The regular occurrence of this session gives an invitation to share that feedback. Examples are opaque decision making (reducing motivation) or deviations from process (creating inefficiencies).

The gist usually is: Sometimes it’s just a small change for an individual that makes a big difference to others. The feeling of being heard itself can be a driver of a good working environment.

Which brings us to the next topic

CULTURE — Execute ruthlessly

Culture is difficult to understand or navigate — but it’s there. Always.

If execution would be a Tesla — strategy would be each component. Agile would be how each component interacts with each other, like if you turn the steering wheel, the wheels turn as well. Then culture is your charging station.

The charging station is symbolic for the work environment. It’s not what you do (strategy) and how you do it (agile). it’s the energy level of your execution.

To execute ruthlessly, culture needs to be a power source, not a power drain.

Culture can be divided in three pillars: individual mindset, team interaction and customer engagement.

The individual mindset is about standards that each member sets for him or herself.

While it might seem counter intuitive, from my experience, individuals set standards not based on their own preference, but primarily in response to their peers. If you come into an ambitious team, you are setting yourself ambitious standards.

For instance, working in investment banking, a traditional high-performance culture, the common mindset is that everyone is keen to be seen as ahead of the pack.

Not everyone has the ambition to be number one, but no one wants to be last. Therefore, everyone sets their standards slightly higher, which leads to peers raising their standards, creating a flywheel.

As an organization, culture starts with the mindset of each individual. When new hires come in, do they feel challenged, accept a challenge & raise their standard?

A leadership team has two ways to influence individuals’ mindsets: Being a role model & meritocracy.

Leaders must be role models for ambition. If unambitious targets are set or too much organizational slack exists, ambition decreases, and each individual will lower their standards.

Meritocracy is a great reality check to validate if organizations foster a high-performance culture. Are people promoted based on time served? Or is the age structure heterogeneous within one management layer?

Individuals who see their managers & peers being ambitious and see plenty of career examples of upward mobility, will set higher standards for themselves.

Higher standards are essential for a growth mindset and therefore the learning curve of your organization. This is essential to accelerate, not decelerate, your execution.

The second pillar of culture is team interaction.

This is usually what people anticipate culture to be all about — how are team members communicating with each other? Is the conversation hostile or friendly?

Team communication is critical for ruthless execution. If teams are pre-occupied figuring themselves out, there is no time left to figure out what product to build.

A team needs to be aligned, to streamline efforts. Two values are critical: being empathic & candid.

Being empathic makes interactions comfortable. Being empathic is only secondary about being nice, but primarily about acknowledging & respecting the perspective of my counterpart.

Conversations need to be around what my counterpart understands & values. A product manager that approaches an engineer with “I want X because I need Y”, will create friction. Better: “if you create X, we achieve Y, which is good because Z”.

Empathy enables better execution because there will be less leakage. Conversations will be fewer & shorter. Tasks are not only better understood, but practitioners will have greater motivation, given they understand the “why”.

Starting to think more about others than yourself, builds the muscle to be purpose — driven. Considering your audience, it will become easier to set meeting agenda’s and clearly communicate where support is beneficial.

Being candid makes interactions efficient. Peers are the first line of defense. For no one it is easier to recognize constructive feedback than for peers. But how many times did you walk over to your peer and told him what he/she can improve?

In most organizational cultures, a candid interaction, especially peer to peer, is unheard of. A drain of power.

Saying “this is interesting”, instead of “this needs more work”, makes you a nicer person, but is a missed opportunity to better execute.

Due to your peer’s proximity to your work, their tactical advice is a source of power. To tap into it, candid feedback needs to become frequent, so that it’s common.

Analogous to culture being the charging station, it needs a steady flow of power. Not too much and not too little.

The retrospective ceremony is key of finetuning the flow. It allows team to ask for less or more. Because the retrospective is a reoccurring meeting, its perfectly suitable for candid feedback. This makes it the ideal lever to adjust to build a healthy team interaction culture.

A candid culture helps teams (& their manager) holding everyone accountable to their objectives, making sure execution stays on track.

Executing ruthlessly will feel uncomfortable at times. If being candid is not a onetime event, but an integral part of the culture, it will make feedback a gift.

Lastly, the cultural approach to customer engagement not only amplifies your culture externally, but also drive urgency.

Talking to customers can be anything between insightful and annoying. Urgency is what makes it worthwhile.

If you are not able to reflect standards, it will be tough to scratch anything but the surface.

If you are not able to interact empathically & candid, it will be tough to understand & uncover real pain points.

This will hamper execution.

When an organization is able to do well on the first two dimensions, it can use customer engagement to benefit execution.

An organization then needs to open the pathway for customer engagement to various parts of the organization. The unlock for agile is the focus on outcome, not on output. Without customer pathway, it will be difficult, if not impossible, for teams to execute.

Therefore, building a culture that embraces customer engagement is vital. Teams where non-client facing roles drive organically to shadow sales calls, participate in workshops or similar opportunities (at least passively) engage, is a telling sign for customer focus.

Teams can build a customer focused culture by putting an effort into tracking customer input diligently. There are different levels: Is it scribbles in someone’s notebook? Is it text in a document? Is it a systematic approach tracked in a spreadsheet? Or are they using a dedicated software to aggregate multiple sources of inputs?

Practitioners are able to infer to what extent their organization values a customer engagement culture by how work is delegated to them. Is it a ‘please add feature X’ or the product manager explaining requirements from a customer perspective (e.g. ‘customer want to do Y, therefore we want feature X’).

If investing in culture seems like an obscure product of chance, the organization is likely an undiagnosed but ill patient.

One who experienced a high performance culture will immediately spot a low performance culture and will either adapt or leave.

A good leader, that embraces an individual mindset with high standards, empathic & candid team interactions and urgency around customer engagement, is one of the best investments a company can make.

CONCLUSION

As the old saying goes — great ideas fail with poor execution and mediocre ideas succeed with great execution.

Executing ruthlessly is no easy feat. It’s about bringing together strategy, agile delivery and culture.

Agile delivery & great culture will fail with poor strategy, as teams will run in circles without direction.

A great strategy & culture only will fail with non-agile delivery, as teams will be pre-occupied fighting bureaucracy & process, rather than building a product.

A great strategy & agile delivery itself will fall apart with poor culture, as teams won’t follow suit.

Being in the center of that Venn diagram increases the chances of success.

So — What really is the difference between a great idea and a great product?

Ruthless execution.

Because ruthless execution gets you from idea to product.

Do you need help with execution?

• Learn more about our Growth Advisory or our Venture Studio.
• Reach out on Linkedin.