My team just got promoted. Recreational league, nothing glamorous. Nobody’s getting scouted. The post-game drinks cost more than our kit. But the question that’s been rattling around my head since we clinched it is the same one that keeps me up when I think about product teams, youth academies, and championship dynasties: what actually makes some teams better than others?

Not just once. Consistently.

It’s a question that sounds simple until you try to answer it. Talent? Sure, but plenty of stacked rosters underperform. Leadership? Depends on what kind.

Culture? The most overused word in business after “alignment.” Money? Ulm’s youth academy outproduces clubs with ten times the budget. My recreational team doesn’t even have a budget.

So when I stumbled on Ron Friedman’s piece in Harvard Business Review — “How to Build a Superteam That Keeps Getting Better” — I read it the way I read anything that touches a question I actually care about: fast the first time, slow the second, skeptical the third.

Here’s what stuck. And where I’d push back.

The research is solid. The framing is interesting.

Friedman’s team surveyed more than 6,000 knowledge workers and identified what separates “superteams” from the rest. The headline finding: the best teams aren’t the ones with the most talent or the best strategy. They’re the ones that learn faster. They build cultures of continuous improvement — not as a poster on the wall, but as a daily habit.

Three strengths stood out: managing time, energy, and attention better. Actively making each other better. And — the one that caught my attention — continuously building new skills and improving over time. But I was also suprised that processes, the poster child of Kaizen, were suprisingly absent from the list.

They open with the OKC Thunder. 58 losses in 2022. Then 40 wins, 57 wins, 68 wins — each season blowing past Vegas projections by double digits. Champions by 2025 with the youngest roster ever to earn a number one seed. The article argues it wasn’t a lucky draft or one superstar. It was an organizational habit: the entire system was designed to improve every year, regardless of starting position.

And here’s the part that gets me: the Thunder did this twice. After relocating from Seattle in 2008, they rebuilt and reached the NBA Finals within four seasons. Then, when star players left and spending rules forced another rebuild, they did it again. Sam Presti, the GM, traded away All-Stars in their prime for draft picks before that strategy was fashionable. He scrapped the traditional lineup format — one center, two forwards, two guards — and experimented with lineups featuring two centers, no center, three point guards. “A big part of our success,” Presti has said, “has been our tolerance for the messiness and even the regression of pursuing progress and growth.”

That line alone is worth the read.

I buy it. Mostly.

Where I agree: “What are you stuck on?” is worth more than any standup format

Of the seven habits Friedman identifies, the one that struck a chord with me was the simplest: superteam leaders routinely ask “What are you stuck on?” The data backs it up — superteam leaders are 43% more likely than average-team leaders to steer discussions toward problems that need solving.

That’s it. One question. No framework. No retrospective template. No Miro board.

I’ve led product teams for years. I’ve run standups in every format imaginable — async, sync, walking, written, fifteen minutes, five minutes, the ones where you hold a ball. The dirty secret is that most status meetings are theater. Everyone reports progress. Real problems stay underground until they’re expensive.

“What are you stuck on?” does something different. It normalizes struggle. It surfaces friction early. And it shifts the social contract from “look competent” to “let’s actually fix things.”

I’ve started using it in our recreational league huddles too, by the way. Turns out even amateur athletes hide their weaknesses unless you ask directly. The point guard who can’t read pick and roll coverages will continue to turn overt the ball until someone creates the space to say I need help with this.

Where I agree but want more: experimentation without consequence is just theatre

Friedman argues superteams “never stop testing.” They run experiments even when results are already good. The numbers: superteams reported experimenting nearly 50% more often than average teams. They’re 30% more open to trying new things and 39% more comfortable taking risks. Their leaders are three times more likely to reward intelligent risks, even when outcomes fall short. Reid Hoffman dared his LinkedIn team to fail 15% of the time. Reed Hastings got nervous when too many Netflix shows were hits — not enough risk-taking. Fine, I’m sold on the premise.

But here’s the part the article doesn’t really address: experimentation only works if there are actual consequences to the learning. I’ve seen plenty of teams that run experiments. A/B tests. Spike tickets. “Discovery sprints.” The experiment happens. The learnings get written up. And then nothing changes because the roadmap was already committed six weeks ago or the second iteration gets delayed to the point where it never happens.

The habit isn’t experimentation. The habit is acting on what you learn, even when it’s inconvenient. That’s the part that requires courage, not process.

My recreational league team learned this the hard way. We weren’t exactly in game shape at the beginning of the season and the intensity during practice did not prepare us to handle the pressure we would face in competition gracefully. We lost three of our first five games. The temptation was to go back to what was comfortable. We didn’t. We tried a different style of exercises, amped up the intensity. But that intermediate period - where the experiment is failing (or not showing any results yet) and everyone wants to revert to old habits - that’s where most teams quit. The article mentions celebrating smart risks. I’d go further: you need to protect experiments long enough for them to actually produce signal, not just noise.

Where I’d push back: “roll up your sleeves” needs a massive asterisk

The article claims leaders of superteams spend “real time in the work.” They cite Brian Chesky’s post-pandemic turnaround at Airbnb - he’d stepped too far back, lost sight of what made the product good, and had to reimmerse himself. Paul Graham turned it into “Founder Mode” and it went viral. The data shows superteam leaders are far more likely to jump in and contribute than to delegate and observe. A study in the Journal of Organizational Behavior found that managers who work alongside their teams actually feel more energized, while those who manage from a distance report higher stress. The logic: when you lose visibility into the work, you spend your days reacting to problems you never saw coming.

I’m... cautious here.

Yes, a leader who’s completely disconnected from the work makes bad decisions. I’ve seen the slide-deck executives who couldn’t tell you what their product actually does. Chesky’s story is real and I have met several CEOs that seemed to be completely detatched from reality myself. That’s a problem.

But I’ve also seen the opposite dysfunction: the leader who’s so deep in the weeds that nobody else grows. The PM who rewrites every ticket. The tech lead who reviews every pull request and is willing to draw blood on code indent discussions. At some point “rolling up your sleeves” becomes “I don’t trust you to do this without me,” and that’s corrosive. The article does make the distinction between involvement and micromanagement: “strong leaders build capacity; micromanagers leave people dependent”, but it breezes past it.

The question isn’t whether leaders should be close to the work. It’s how close, for how long, and when to step back. The best leaders I’ve worked with have an almost rhythmic pattern: they go deep, absorb context, then pull out and let the team run. They’re close enough to guide, far enough to let people own their work. Presti, the Thunder’s GM, still spends most of his year on the road scouting players in remote gyms. That works because scouting is his work. The danger is when leaders romanticize being in the trenches as an end in itself.

The part that’s genuinely underrated but hardly instrumental: meaning over metrics

The last habit,“lead with meaning, not just metrics”, is the one that sounds the softest. It matters, but it is hardly instrumental.

Friedman points to the Thunder tying their identity to the values of their city. When Presti arrived in Oklahoma City, he visited the National Memorial for the 1995 bombing and found a Tom Brokaw quote about the city’s people: “In their response to this madness they have elevated us all with their essential sense of goodness, community, and compassion.” That quote shaped the organization’s identity. Today every new player and staff member visits the memorial upon arrival. It’s not corporate values on a slide deck. It’s a ritual that connects the team’s culture to something real.

The research says superteam leaders are 59% more effective at helping teams understand why their work matters. And when they do, “good enough” stops being the standard.

I’ve experienced this firsthand. Not at the boardroom level, but at the recreational league level. When our team talks about why we play — not the results, but the challenge, the improvement, the commitment to each other, to the team - people show up differently. They run harder in the last ten minutes. They come to training when it rains. Camaraderie in its purest form.

At work it’s hardly the same. Yes, it is motivating to ships something for a specific user whose life gets measurably better because of it. But others might find meaning in the mastery that comes with the ambition to continuously improve ones craft. Others might find meaning simply by working with nice people and earning money to provide for their family. What we find meaningful is deeply personal. And it is presumptous to demand the workplace to be that source of meaning for everyone in the same way.

What the article misses

Two things.

First: the role of conflict. The article paints superteams as environments of psychological safety, curiosity, and supportive feedback. It cites Google’s landmark study of 180 teams that found psychological safety is the single strongest predictor of team performance. Over 90% of people on superteams say their manager gives feedback that motivates without sounding critical - and a meta-analysis of 600+ studies found that in a third of cases, feedback actually worsens performance when delivered poorly. All important. But it skips the uncomfortable part: the best teams I’ve been on also had real arguments. Not toxic ones - productive ones. Disagreement about approach, about priorities, about what “good” looks like. Safety doesn’t mean comfort. It means you can disagree without getting punished for it. That distinction matters. But an overly concern about people feeling uncomfortable stifels healthy conflict just as much as toxic behaviors.

Second: the composition problem. You can have all seven habits and still lose if you don’t have the right people in the right positions. No amount of curiosity or experimentation fixes a fundamental skill gap or a personality mismatch. The article focuses on culture and behaviour, which is valuable, but culture is a multiplier, not a substitute. Zero times any multiplier is still zero.

So what actually makes a team great?

Honestly? I think it’s boring. It’s not one thing. It’s the interaction of several things that are each individually unremarkable:

The right people who trust each other enough to be honest. Who experiment and actually follow through on what they learn. Who have a leader close enough to understand reality but restrained enough to let others grow. Who are connected to something beyond the next deadline or the next game.

That’s it. No framework. No acronym. Just a handful of habits practiced with annoying consistency.

My recreational league team isn’t a superteam. We’re a group of people mostly in our late thirties who are probably too competitive for a hobby league. But we got promoted because we did a version of what Friedman describes: we kept learning, we stayed honest about what wasn’t working, and we cared about getting better more than we cared about looking good.

The HBR article is worth your time. Read it critically, apply it selectively, and don’t expect a checklist to do the work for you.

Based on: Ron Friedman, “How to Build a Superteam That Keeps Getting Better”, Harvard Business Review, May 2026. Adapted from his book “Superteams: The Science and Secrets of High-Performing Teams” (Simon & Schuster, 2026).

Questions worth sitting with

1. When did your team last run an experiment that actually changed something — not just confirmed what you already believed?

2. Do your meetings surface real problems, or do people save those for the hallway?

3. Is your leader in the trenches because they’re curious, or because they can’t let go?

4. What would your team do differently if you replaced your metrics dashboard with one question: “Why does this matter?”

5. Are you building a team, or are you assembling talent and hoping culture happens?

The Wrong Debate

The current discussion is broken.

AI vs. no-code vs. “real” code - framed as a replacement battle. As if one will win and the others will die. As if we’re picking sides in a religious war.

This is a category error.

These are not ideological camps. They’re tools with different effort-to-complexity curves. And if you’re arguing about which one is “the future,” you’ve already lost the plot.

The interesting question isn’t which tool wins. It’s where each tool belongs.

The Effort-Complexity Curve

Let’s build a simple model. X-axis: complexity. Y-axis: cost and effort.

Now draw three curves.

AI-generated systems start with the lowest entry cost. Minimal skill barrier. Absurdly fast for simple artifacts - websites, forms, automations. Things like Lovable or prompting your way with Claude Code without ever actually opening an IDE falls into this category. But the logic is opaque. And the exponential failure point appears early. Add scale, add interdependencies, and watch it buckle.

No-code sits in the middle. Higher entry cost than AI (licenses, learning curves). But more deterministic. More transparent. Handles structured workflows better but you might run into limiting constraints every now and then. The exponential scaling pain occurs later - but it still occurs. At FINN we had Airtable as a case study: brilliant until your data architecture wasn’t designed for growth nor for portability, and suddenly you’re rebuilding everything.

Pro-code has the highest initial cost. Expertise, salaries, time. But you get full control over architecture. Highest resilience under scale. The exponential complexity breakpoint sits furthest to the right.

Here’s the insight nobody wants to accept: each approach dominates in a specific complexity range. Not everywhere. Not forever. In a range.

The Architectural Mistakes

Two extremes dominate the discussions around these. Both are wrong.

The Pro-Code Purist

The assumption: every system must belong to the core.

The consequence: everything gets treated as mission-critical. Every small workflow becomes architectural overhead. Every request goes into the backlog. Innovation dies in sprint planning meetings.

These teams ignore modular boundaries. They build cathedrals when they need tents. And they wonder why the business keeps complaining about speed.

The AI / No-Code Maximalist

The assumption: everything can be built with AI or no-code. Just wire it up. Ship fast. Iterate.

The consequence: scaling fragility. Hidden technical debt. Opaque logic under load. Data inconsistencies that nobody can trace. Security risks that nobody understands until the audit.

These teams underestimate B2B complexity accumulation. They build tents when they need foundations. And they wonder why everything breaks at scale.

But here’s the contradiction: both camps are partially right. Not every system needs to be mission-critical. And not every workflow should be handed to engineers. The question is how to separate them.

The Core & Satellite Model

Think of it as planetary architecture.

The “core” is the planet. The “satellites” are moons. Gravitationally attatched to the core but independent.

The Core (Should be Pro-Code)

The core handles:

• Data integrity

• Authentication and authorization

• Security

• Validation logic

• Scalability

• Auditability

• Core APIs

The core absorbs high load, cross-system dependencies, and mission-critical workflows. It doesn’t move fast. It moves right.

The core must be engineered. Full stop. No discussions.

The Satellites (Should be AI / No-Code)

The satellites are different. Lightweight. Independent. Loosely coupled. Replaceable. At best user-maintained.

Examples:

• Internal tools

• Micro-automations

• Landing pages

• One-page apps

• Workflow-specific dashboards

• Temporary experiments

They connect to the core via APIs, webhooks, MCP-style interfaces, validated endpoints. They consume systemic truth. They don’t own it.

Satellites are allowed to fail. That’s the point.

Why This Model Works

Risk Containment

If a satellite fails, it doesn’t collapse the planet. You can cut it off. Users complain, you rebuild it, life goes on.

If the core fails, everything collapses.

Therefore: stability lives at the center, experimentation lives at the edge.

This isn’t just architecture. It’s organizational risk management.

Cultural Leverage

The real unlock: empower staff to build satellites.

Give them access to clean APIs. Give them clear governance rules. Give them guardrails around data access. Give them a defined escalation path when something needs to migrate to the core. Finally, give them the tools of your choosing, and let them build. I’ve seen this work at multiple companies now (FINN & Jobvalley), and the results are convincing.

What you get: increased autonomy, faster local optimization, reduced bottlenecks.

What you avoid: the engineering team becoming a bottleneck for every internal tool request.

Central reliability. Distributed innovation. That’s the trade.

Complexity Management

The key mistake most organizations (especially enterprises) make: treating all software as core software.

Small tools don’t require full scalability guarantees. They don’t need enterprise-grade lifecycle management. They don’t need heavy governance.

Overengineering small use cases destroys speed. Underengineering core systems destroys companies.

This model separates the two. On purpose.

The Transition Threshold

Over time, some satellites grow.

Usage increases. Dependencies multiply. Revenue depends on it. Compliance risk rises.

At some point, the satellite migrates inward. It becomes core.

This creates a natural evolution path: Experiment → Validate → Stabilize → Institutionalize.

Not everything starts as infrastructure. But some things become infrastructure. The model accounts for that.

What Large Organizations Underestimate

Tools alone are insufficient.

You need:

1. Core APIs with validation

2. Clear data ownership

3. Permission architecture

4. Monitoring

5. Defined integration standards

Without this infrastructure, AI tools stall. AI-Tools become shadow IT. Security blocks everything. And the organization ends up worse than before - more tools, more chaos, less control.

The bottleneck is not tooling. It’s architecture.

The uncomfortable truth: most organizations want the benefits of distributed innovation without investing in the enabling infrastructure. They want moons without building the planet first.

Strategic Positioning

Here’s where I land:

• AI is the lowest-friction entry layer. Fast experiments. Disposable artifacts. Rapid prototyping.

• No-code extends structured autonomy. Workflows that need to persist but don’t need to scale globally (even though there are tools like Xano which seem to scale quite nicely).

• Pro-code absorbs systemic complexity. The stuff that can’t fail.

None replaces the others. They coexist.

The intelligent organization:

• Designs a hardened core

• Exposes clean interfaces

• Enables controlled chaos at the edges

• Accepts replaceability of satellites

• Protects irreversibility in the core

Questions Worth Sitting With

1. What’s currently in your “core” that should be a satellite? What’s a satellite that’s quietly becoming load-bearing?

2. Is your engineering team a bottleneck because they’re protecting quality - or because you haven’t built the interfaces that would make satellites safe?

3. When a no-code tool fails at scale, do you migrate it inward or patch it forever?

4. Are you debating AI vs. no-code vs. pro-code ideologically - or asking where each belongs on the complexity curve?

5. What would it take to give your staff permission to build at the edge - without creating security nightmares?

---

The debate isn’t which tool wins.

The real question: where does each tool belong on the complexity curve?

Stability at the center. Speed at the edge. Interfaces in between.

Your move.

.

Agility is, without question, still a top contender in the category of “buzzwords everyone uses without having understood the principles behind them.” As a result, the term’s impact is steadily eroding, and the actual core of agile leadership principles gets dismissed as hype. That is unfortunate, because these principles are meant to provide orientation for how to act effectively in a context defined by uncertainty. You know—VUCA.

The hype is driven by consultants. They now call themselves Agile Coaches and keep armies of people busy sticking Post-its to digital and analog walls. The marketing mistake made by this personified version of agility is obvious: it tries to sell supposedly new principles through new people and new methods. Not exactly a strong foundation for credibility. And this is not about resistance to change or a lack of insight that the world is changing. It is far more a matter of scientific skepticism: principles that claim a certain degree of general validity should be based on a much broader body of evidence than software development and companies from Silicon Valley. That is a legitimate objection.

The tragedy is this: there is far more evidence that agile principles do have general validity. People just don’t talk about it, because some advocates, riding on the coattails of agility, insist on smuggling in New Work utopias such as the abolition of hierarchy and universal individual self-actualization.

Take the Japanese in the 1970s. A textbook example of hierarchical conformity. As early as 1986, Hirotaka Takeuchi and Ikujiro Nonaka published the article “The New New Product Development Game,” describing how Japanese companies in the 1970s developed products quickly and flexibly that matched the spirit of the time. The word agility does not appear, but the authors describe the conflict that sequential planning in the sense of the waterfall model is incompatible with the speed and flexibility demanded by markets. And we are talking about cameras, printers, and cars—products that still have comparatively long life cycles. They conclude that companies are successful in developing new products when they:

• have a clear goal

• build interdisciplinary, autonomous teams

• follow an iterative process that fosters learning and enables rapid adaptation

This sounds very much like the standard demands of any agile transformation. Not by coincidence, Japan established its dominance in the electronics and automotive industries during this period. Part of this was later successfully imported into Europe in the form of Kaizen (learning through iteration) and Lean Production (shared responsibility for quality and process improvement). The continuous improvement process should still be familiar to every employee in a manufacturing corporation today.

But it gets even more extreme. The absolute antichrist of the agile hipster: the Prussian military. Uniformity, obedience, and discipline combined with a strict hierarchy - I can hardly imagine a better nemesis. And yet I claim: Carl von Clausewitz and Helmuth von Moltke are the real godfathers of agile leadership.

In his magnum opus On War (circa 1832), Carl von Clausewitz writes that one can never truly be certain of one’s “knowledge of the enemy and his country, which forms the basis of all our ideas and actions.” “Consider the nature of this basis,” Clausewitz continues, “its unreliability and variability, and one will soon sense how dangerous the edifice of war is, how easily it can collapse and bury us beneath its ruins. […] A large part of the information one receives in war is contradictory, an even larger part is false, and by far the greatest part is subject to considerable uncertainty.” “Three quarters of the factors on which action in war is based are shrouded in a fog of greater or lesser uncertainty.”

Yes, even in the 19th century, war was highly VUCA. Instead of an acronym, the metaphor was “the fog of war.” The challenge then, as now, is that we do not know what lies ahead of us. So how do we deal with it? Hemut von Moltke, a successor in thought of Clauswitz - also declares the waterfall model obsolete, because “only the layman believes that in the course of a campaign he can discern the consistent execution of a preconceived plan, worked out in every detail and adhered to until the end.” In reality, the approach was usually far more agile. The objectives remain the same, “but the paths by which [the general] hopes to reach them can never be determined with certainty far in advance. Throughout the entire campaign he is dependent on making a series of decisions based on situations that cannot be foreseen.” Moltke is, in effect, defending every product manager who once again has to explain why the current roadmap is non-binding.

The challenge, Moltke continues, is “to correctly assess what is given, to guess what is unknown, to make a decision quickly, and then to carry it out forcefully and without hesitation.” Eric Ries would say: generate hypotheses based on data and rapidly and decisively test their assumptions through experiments. I am grateful that my product decisions usually do not entail gambling with the lifes of people, but if this idea holds up in truely existential circumstances, then it must be true for the release of web app.

“As a result of these ideas, the principle of mission command was developed, following a clear logic: because a superior can never fully oversee everything happening on the battlefield, foresee all contingencies in detail, or directly influence the actions of his troops, only the objective to be achieved is specified to the subordinate, while the details of execution are left to him. Thanks to the resulting strengthening of personal responsibility at lower levels of command, rapid and decisive action is possible even in unclear situations.” (Bühlmann & Braun, 2010)

Clear goals and autonomy in execution in order to respond flexibly to changing conditions—this is exactly where we find the principles of agile leadership that we are so quick to dismiss today as a modern hype. And the Prussian military was highly successful with this approach. Not only under Helmuth von Moltke in the three wars of German unification, but also in the subsequent world wars, extraordinary military achievements were accomplished on the basis of mission command. It is no coincidence that mission command is still considered best practice worldwide today, especially among elite units.

I understand the reflex not to want to learn from war and the military. Killing and destruction do not fit into a humanitarian worldview. And in the circle of chairs where we are supposed to practice nonviolent communication together, associations with Prussian officers and generals are of limited help. Nevertheless, we should acknowledge that the principles of agile leadership do not work only in the context of mate-drinking millennials in Berlin building the next dating app. These principles have proven themselves for more than 100 years in a wide range of dynamic environments.

Detached from the often annoying methods and the agile snake-oil salesmen, we can accept that these “hyped” principles have always been the foundation of good leadership. Maybe the coaches should really try wearing a spiked helmet (German: Picklhaube) and build a bridge to the virtues of the eternally conservative. That might even convince them of the proven principles of agile leadership.

Subscribe now

Vibe-Coding and NoCode has been hyped in the past year. As usual “clickbaity” headlines dominate the feed with predictions that these tools will replace engineering teams. That a few prompts will create software in minutes that would have take entire engineering teams months if not years.

I’ve worked intensively in the past years with the tools and I can confidently claim that the hype is well deserved but misdirected.

Just as many engineers but more makers

The way I see it there are three different categories of tools on the market.

1. Prompt builders. The promise: Build production ready software just by writing instructions. Examples are Lovable or Base44. And they do work. Limiting factor is understanding software to the extent that you can clearly articulate what you want to be build. This is easy for small applications or websites but becomes increasingly difficult for complicated backends embedded in a complicated context. In practice these tools can become frustrating when you are forced to itereate towards increasing complexity. It might be just me (and the persons I talk to) but at some point these builders tend to do stuff that you didn’t ask them to.
   The barriers of entry are very low but the return on investment quickly decreases with complexity. As soon as prompts no longer do what you want them to do, you find yourself in a cule-de-sack. If you are lucky these tools allow you to export the code base so you can edit it the old fashioned way. Which also means you need “pro-code” skills at that point. Some freelance-engineers already have identified that need as business opportunity and are targeting their services towards vibe coders who got stuck.

2. Interface builders. Interface builders have a very long history - starting with WYSIWYG-website builders (What you see is what you get). But including classics like Dreamweaver or web 2.0 icons like Wordpress - these systems were limited to mostly frontend applications. With a bit of tech know how and couple of templates, you can quickly learn to build a homepage maybe even an onlineshop. Some knowledge in HTML and CSS was helpful but not necessary. But you can’t really build custome software with these. Things started to change with tools that additionally offer process features or are exclusively focused on backend processes such as n8n, Make.com or Xano.
   The principles of these tools is the same: They offer an interface to the user that is easier to understand and use than “real code”. In some way it is still code but on an additional abstraction layer. E.g. Make.com represents functions as a sequence of steps shown as interconnected bubbles with the option to determine conditions that route the process.

   This example already illustrates that these tools already require some basic understanding how algorithms and software works. But in comparison to “pro-code” these tools are much more accessible for beginners and it easy to just get going while already making stuff that creates value such as automating a simple data transfer. A lot of these interface builders have features that link to the other two domains - the option to create by prompting and the option to add code snippets.
   A downside, that you should be aware of, is that most tools lock you in their environment. E.g. you can’t just export your Make.com flows and run the workflows on your local machine. Same is true for Bubble, n8n (even if you can run that on your local machine…it still needs you to run n8n), or also for the API part of Xano. Another downside is, that there are some tradeoffs regarding flexibility. There are cases where you have to be fine with workarounds. Nevertheless I personally love these tools as they hit the sweet spot for me on the control vs. usability trade off.

3. Coding Copilots. Copilots work in an IDE or an environment that looks very similar to one. So this is an interface that no longer shows a representation of code but code itself. The AI tools like Cursor or Windsurf do their work in that environment. While you instruct these co-pilots via prompts the output is real code. The upside productivity-wise is the same as for prompt builders. You can create massive amounts of code and functionality in the matter of minutes. The down-side is similar as well: Sometimes “things” happen - go off the rail and it no longer does what it is supposed to do. At this point your only option is to (once more) actually understand what your co-pilot has been coding in oder to adjust the instructions or adjust things yourself. Meaning, after all, when you work with copilots you should understand the code the copilot is writing from the get go. So this is a powerful tool for developers. Non-engineers can create simple applications with it as well but run risk to dig themselves into once the software gets more complex.

The coding copilots - even though they have the option to make engineers much more productive - will not replace an engineer, as you still should have coding expertise to use it properly in my opinion. I am also yet to work in a company where we truely felt like we have “enough” engineers considering all the requirements and opportunities in the backlog. So I think there is lots to be gained. I might be wrong though when it comes to junior developers in big companies. Other than that I would expect the copilots to increase the output of engineers, not replace them.

The powers of coders to the masses

The other two - prompt and interface builders - are interesting though, as you don’t need much expertise to get started and you get quickly proficient enough to create value. Personally it took me less than two months from logging in to Make and Retool for the first time to automating the B2B invoice at FINN and creating a custom offer creation tool for the sales team. And it is by no means a special ability: If you were able to learn a tool like Excel by occasionally googling, you are probably smart enough to learn how to use an interface builder.

The revolution (yes - big word but I think it is no less) is that this allows people without real coding expertise to create digital products. It allows people to build products they need themselves. Products being anything that creates value for the user - from a simple automation to a complete marketable software.

And these people are uniquely qualified to do so as they are the experts themselves. They leverage their domain expertise to create solutions for themselves or others, working alongside IT to speed up innovation and reduce the burden on professional developers, who can focus on the core system and more complext tasks.

The ability to make things yourself creates a new leverage for these experts and replaces the previous dependency on either, a central IT team that quite often is a bottleneck, or an expensive external agency. The power that was concentrated before in the hands of expensive developers and servicde providers, is now accessible to a much wider audience.

Additionally, the creation process is even more efficient as there is no communication inherent loss of information from user to product management and eventually to developer. I wouldn’t go so far to argue that the managerial level of work will become obsolete in the product realm, but the workload will certainly be reduced (No-code architecture is yet another monster to slay. Probably something for a future post).

My appeal for entrepreneurs and executives alike is to realize that by extending the maker leverage you set yourself up to realize the potential of digitalization in general (yes…there is still work to be done - even decades later) but also set yourself up to take advantage of new technologies such as AI and take advantage of new software tools by immediately integrating them into your system. The potential within the current workforce is vast and it is now your turn to provide them infrastructure to get started

.

When I am trying to push a singular focus during sprints or even for entire quarters, I have received plenty of pushback in my career. Focus implies that that we commit to one thing and decline an infinite amount of other options. Naturally, this triggers a fear of missing out.

This fear is fed by several misconceptions. First, a "no" at the moment must not be a "no" forever. It is just a definitive "no" right now. Second, doing more things doesn't mean you get more things done. More often then not the opposite is true. Third, we treat "slack" like it is something to be avoided and try to stuff our roadmaps and sprints. But actually planned slack, allows you to react to unplanned changes and new insights.

When researching why tackling mutliple topics in parallel hurts productivity I found that the crux is understanding switching costs.

Switching Cost and overhead - the expensive price for multitasking

Everyone whose profession requires some kind of deep work has experienced this himself. You are currently focused on working on a complicated topic, like an essay, a piece of code, or the presentation for the next board meeting. You progress consistently until a bing from your messenger confronts you with an urgent problem from a customer that requires your immediate attention. After you extinguished the major fires, you return to your previous work. Instead of seamlessly picking up where you left off, you likely found yourself stuck for 10 minutes or more trying to get a grip on the loose thread.

The reason for that is the switch in context. Your brain needs to invest energy and time to clear the mental ram and recall and refill it with the information of the former context. If this analogy is too technical, envision a desktop with loads of papers on it that you have to put away before you start to work on something else, so you can put all the stuff on the desktop that you need for your next task.

Some experts claim that these switching costs can take-up to 20% of available time with each additional project. Hence, when working on 4 projects simultaneously, we spend more time context switching than working on the actual project itself.

The origin of switching costs

The origin of these issues can be traced back to our human limitations. Humans are not build to multitask and our mental capacity is limited.

Based on over a half-century of cognitive science and more recent studies on multitasking (which is nothing else than rapid switching between tasks), we know that multitaskers do less and miss information. Efficiency can drop by as much as 40%. Long-term memory suffers, and creativity — a skill associated with remembering multiple, less common associations — is reduced.

When it comes to switching (not really trying to do two things at the same time but switching from one to the other), studies on distraction indicate that it takes an average of 15 minutes to re-orient to a primary task after a distraction such as an email.

Adding insult to injury, even in the rare case where we can focus, studies indicate that we can only keep up to four items “in mind”.1

So, our actual working memory is very limited, and this explains why most knowledge workers depend on todo-lists, project plans, and other systems to keep them organized.

The evil twin of switching costs: Project overhead

While the switching cost are paid mentally by individuals, project overheads are transactional costs on an organizational level. Overhead costs are created by all the efforts to report and align on ongoing projects. These are the alignments that you have to be in to “stay in the loop” about topics that should be handled but you know that they won’t be top on you list for some time.

Or all these updates where you are supposed to update on the progress of a project that hardly progresses at all, as it just one of many. These are all activities that are valuable in the sense of coordination but not in the sense of value creation. And unfortunately they take away scarce time that could be used for value creation.

So in an ideal world, I could stop with the obvious conclusion that wherever and whenever possible, limit the number of projects that are “work in progress” (WIP). Unfortunately, most of us are working in a system that makes it almost impossible to keep WIP small. So what now?

How to reduce switching costs when you can’t focus on a single topic

Let’s face it: Most of us working in product face an onslaught of different topics screaming for our attention. New features, retention, strategy, bugs, tech-debt, stakeholders, discovery, all of these tasks require the attention of the product trio continuously. So how do we reduce the negative impact of switching as much as possible?

Ruthless prioritization

Being very clear on “what is the most important task right now” helps. Needless to say that this also includes sticking to that decision until the task is complete. This works on an individual level (finish this presentation and ignore all other mails and messages until it is done) as well as on a team-level (having a single clear sprint goal). Simply saying “no” to more things already reduces the work in progress significantly for most people.

Cluster activities by domain and similarity

Switching cost increase with the distance between activities. If you investigate several bugs within the same component, switching costs are much lower than switching from your AWS cloud setup to optimizing the responsiveness of your web-app.

This idea aligns with common productivity advice to “batch-process” similar tasks and set up time-blockers to focus on one specific topic at a time.

Batch mundane tasks

Switching costs also increase with complexity. Switching between mundane tasks is very low-cost and can actually be a welcomed change. If you have ever done a "clean-up" sprint where you tend to tackle a bunch of small tech and usability debts, then this was probably this type of tasks. PMs might batch all kind of reporting and admin responsibilities in a similar way.

Use natural breaks to switch tasks

Re-engaging with the same task after a disruption is probably similarly costly as engaging with a different tasks. If there is a natural break either way e.g., lunch break or end of your working day, you might as well make the necessary switch then. For example, Elon Musk is said to divide his schedule so it’s predominantly one company on one day as “switching context is quite painful.”2

Document your last thought and next step

Whenever you are about to switch tasks, jot down your next thought or step. That way you will save a couple of minutes to pick up the thread when you return. Whenever I e.g. can finish up a new newsletter, I try to at least write out the next sub-headlines or some kind of instruction what I would do next to finish the article.

Increase the effort necessary to delegate task to you

To be fair: Good delegation is hard. Good delegation is also much more than the agreement that “someone should do something”. Insist that the task delegator provides sufficient information necessary upfront or that necessary decisions are made before you start on the task. By increasing the expected level of refinement of tasks, ideas or projects that are delegated to you, you will find that the urgency and importance of these quickly decreases. It’s almost embarassing how urgency and importance reduces whenever the delegating party is expected to do something first. From the other side it is somehow understandable that you try to declare every nice-to-have as urgent and important as long as you don’t have to do it.

Let’s say a sales manager approaches you with a feature idea and ends the pitch with the notorious question “Until when can you do this?”. By just claiming you need to discover it first, you already agreed to take on all the research on your own. Instead say something like this: “Sounds like an interesting idea. Can you write all that down in a brief, provide a list of at least five customers for whom this feature will be relevant and who are willing to jump on a call with us?”.

Even the small friction of asking the other to document the ideas in a written form is sufficient to stop some initiatives in their tracks. Ironic, that you were expected to develop the same feature for weeks! By increasing the effort required to delegate tasks to you, you introduce a first quality gate for what tasks end up on your desk after all.

Make your work in progress and roadmap visible

With at least some common understanding that less work in progress and more focus is better, make it clear and visible what you are currently working on. If you are exected to things now, make it clear that this also means that you stop to work on whatever you currently focus on.

Same works for whatever is next on your roadmap. I am not a huge fan of roadmapping but “Now-Next-Later"-Roadmaps” come in handy to communicate what I am currently doing and what I expect to do next. In this cases “Next” usually never extends to much more than the next 3 months. For me this is the time-frame I feel comfortable to communicate commitment and usually is aligned with the quarterly OKR planning cycle. Coveniently it is also a time frame where I feel like I can roughly estimate how much we can get done. So the list of next items is usually small enough to force and make a tradeoff decision.

If initiatives don’t make the “Next” list either, they get an honorable mention in the later column of the roadmap. However, I never comit that these initiatives will be pursued but make it clear that this will depend on future goals, priorities and competing initiatives.

Some of these tips might work better for you, others won’t.
Give them a try. Experiment with them. Use what works. Drop what doesn’t.
Increasing the focus of your team by just a little bit, is already worth the effort.

Hype cycles come and go. We are aware of that. But what remains when the hype is gone? The theory suggests that after we fall from the peak of inflated expectations to the trough of disillusionment we will climb the slope of enlightenment to reach the plateau of productivity. But do we? Some hypes seem to simply disappear or never fully reach the plateau of productivity.

So AI is very much one of the peaking hypes at the moment. And I am wondering how the hype will move forward. As techno-optimist I am … well optimistic, but I wonder if it will face the same challenges as its parents “Big Data” and “Predictive Analytics”. Paradoxically both of them are foundational to the rise of AI but never have seen the wide-spread adoption that was heralded just a decade ago.

Back then data was no longer just records in a database, it was the oil of the information age. In fact, we no longer talked about data in a database but about big data and data lakes. And there were a lot of impressive case studies to kick things off. Target was able to detect pregnancies of customers earlier than the customer’s relatives. And yes, Spotify and Netflix seem to understand my preferences. But outside of that? My car breaks down, but nobody told me in advance. My portfolio crashed and nobody saw it coming.

The inside view in most companies is just as dire as the customer experience. We pay mostly lip service for data-driven decision-making. We use data only to the extent it is easily available to us, handle it with the knowledge of a graduating high school student, and are willing to dismiss all insights as soon as it doesn’t fit our preconceived opinions. So to me, it feels like the data hype fell short. We have seen impressive glimpse of what it can do, but it isn’t the ubiquitous all-star it should have been.

It’s ironic that “big data” and predictive analytics came together for an impressive demonstration of what models that were trained on huge amounts of data can achieve to produce LLMs that became the poster-child driver of the AI-hype.

So since the same buzzword-slinging consultants that told us about being data-driven about years ago are now promising the AI-driven future, what makes us believe that this hype might be different?

A set of inherited issues: Access, quality and trust

There are three reasons why data analytics fell short. It is the lack of access, lack of quality and lack of trust.

Analytics and AI needs access to data. At minimum read access to use available information, at best write access to actually take action. For most companies, especially big ones, it’s not like the data does not exist. It’s just not accessible to everyone who needs it. It’s stowed away in excel sheets, presentations on local drives and on-premise systems with no proper interface. On top of that corporations like to slap a layer of data governance that makes it impossible to get the permissions.

The attempt to simply aggregate all data in a single location (those data lakes) was more like a careless dumping of data, turning the data lake into a data dumpster. An entire generation of enthusiastic data scientists were turned into frustrated data administrators whose main job was fixing messy data instead of sophisticated data models. “Shit in, shit out” was the tagline of this realization.

Lack of quality also fueled the lack of trust in the insights derived from data. It is one of the easiest plays in the book of power: If you are challenged with a conclusion you don’t like, you question the quality of the data it was made upon. Besides the quality issues, we also face a lot of common biases: The confirmation bias (this doesn’t match my personal observations), the control illusion (I feel safer when I make decisions not a computer) and a lot of biases that make it almost impossible to feel comfortable with probabilistic thinking (e.g. loss aversion).

These issues crippled the majority of the data initiatives in most companies and it will also cripple AI.

Let’s look at fictional case of a trouser company. The trouser company CEO loves AI and wants to start off with its sales department automating all out-reach sales calls. Theoretically, this is possible and I heard of companies that made it work: An AI automatically calls leads and tries to capture orders from those customers.

In practice, this is where it becomes difficult:

• The company uses an old CRM system, hosted on-premise on some servers in the basement. It doesn’t have an API that you could use to actually get and update the leads that the AI is calling. (access)

• After updating the CRM (costings lots of time and money) you quickly find out that the data quality sucks. In theory you should have all relevant customer data linked in it but this is not the case. You feel like the CRM is handled mostly by monkeys and your determination to fix the quality issue feels like the saga of Sisyphus. (quality)

• A review of your logs shows that customers often ask questions about your product portfolio and other reference customers. You try to gather all relevant data in single place to make it accessible for the AI (of course it is not accessible yet). No matter what you do, the same monkeys that mess up your CRM are also tasked to keep all product-relevant data up-to-date. You feel like you are almost there, when legal calls to talk about your loose handle on data privacy and reminds you about the strict sharing rules on a need-to-know basis. (access + quality + trust)

• An odd couple of sales and product managers that used to hate their guts surprisingly agree, for the first time: After monitoring the logs they conclude that the AI fails to grasp the nuances of trousers and trouser sales. High potential customers are no longer called by AI (trust)

• On the 100th call, the AI makes a false promise to the customer. The following attempt to right the wrongs leads to the deflection of the valued customer. As a consequence it is now mandatory that every AI call is supervised in real-time by a human coworker who can intervene. This basically nullifies the productivity gain from AI in this use case but I guess we are “just not there yet”. Nobody dares to say that some colleagues made false promises to customers before as well. (trust)

• A quick measure shows that skimming the summary of the sales call and then manually placing the order almost takes up as much time as the not AI call, during which the sellers manually placed the order in the ERP system. The fix to this would be to enable the AI to place the order directly in the ERP-system which, you guessed it, is an on-premise system with no API. It’s also managed by another department and the lead is not shy to announce that letting an AI manipulate data in the ERP is suicide. (access, trust)

This is of course a caricatural narrative, but I bet that it feels oddly familiar in case you work in a large corporation or an older small or medium enterprise. The use case quickly turns from a disruptive change for the better into a minor use case with a questionable ROI. Just looking at that, I would say AI is about to follow in the footsteps of his parents: Some impressive B2B use cases that a mere anecdotes in the grand scheme of things. But there is a slight difference.

The slight difference: AI as your daily companion

I am part of a generation with childhood memories of screeching dial-in modems. In this first wave of the consumer internet I fondly remember writing my first email.

I also remember the first question that came up after I wrote the email: Did it work?

So I called my friend, who I just wrote an email to, to tell him to check his mail. Same goes for the first mails with attachment. Later on mails with attachments larger than a couple of MBs (mailboxes tended to constantly run into limits as you had like 20MB max space available). There was doubt that it works until there wasn’t. Technical miracles turned into technical commodities since then: Who doesn’t read their texts within a few hours?!

Just as the messaging became normal in our private lives first and extended to business second (think Slack and Teams), AI has a chance to pull of the same. Even though it faces the same challenges as Data and Analytics to actually gain traction in most business cases, unlike its parents, it has individual and personal use cases right out the gate.

I use AI for technical or professional questions in case I am stuck or want a quick second opinion. Easy research tasks with public or “private” sources are an absolute no brainer. Sometimes some more creative brainstorming, some text optimisations some structuring to messy thoughts - AI has become a valued companion in my daily work and life. I even use it to determine flower types when I am on hike with my 5 year old.

All of this makes me comfortable with AI and probably also more tolerable for its short comings. Although I remain disappointed in some use cases, it is doing a fantastic job in others.

These experiences others and I are making on a daily basis could be enough to increase trust in this new technology and strengthen the resolve to finally tackle the access and quality issues that will block the most exciting use cases.

I am also aware that I am part of a tech-bubble. So it would be proposterous to assume that my early adoption of AI is shared by most knowledge workers across industries or even across all professions.

We are not there yet, but there is a good chance that we will become increasingly trusting in what AI can do and increasingly tolerable for its shortcomings.

Even though “product market fit” is the holy grail all startups are hunting after, it’s the quality and alignment of the co-founders that is often the cause for failure. According to a questionnaire answered by VCs weak senior management (usually the co-founders) was contributing to the startup’s failure 95% of the time and it was considered to be the most important contributing factor 65% of the time.

So this brings up the big question: Who should you co-found with?

As a general rule of thumb: People you already worked with. That usually implies that you know how to work together and already created some trust or even friendship. In other words: You know what to expect. On the contrary founding with friends you haven’t worked with is as likely to be successful as founding with total strangers.

However, in all cases, I strongly recommend everyone to be as explicit as possible about expectations regarding everything of the startup.

Inspired by a list I originally received from Johann Romefort, I created my own list over time to structure a conversation that surfaces the most important expectations. This is not a small talk type of conversation. This is not a conversation that you should postpone because “things will fall into place”. Look for disagreement in these questions. False agreement can massively hurt you. Keep that as your frame of mind when answering these questions. It’s also totally fine if you feel ambiguous about some questions. Be radically honest and open with each other. I added things to pay attention to or listen for to every question to help you lead those difficult conversations.

1. Personal Values and Motivations

• Why are you starting this company?

  • What is your intrinsic drive?

  • What motivates you most (e.g., impact, wealth, innovation)?

  Pay attention to / listen for:

  • Conflicting motives such as profit vs. sustainability

  • Different levels of commitment

• What are your core personal values?

  • Examples: Integrity, creativity, resilience.

  Pay attention to / listen for:

  • Conflicting values such as structure vs. freedom and creativity

• What are you ready to sacrifice for this venture?

  • Time, lifestyle, control, financial security?

  Pay attention to / listen for:

  • Unrealistic expectations of the sacrifices that need to be made

• What is your definition of success?

  • Personal, professional, and company-oriented.

  Pay attention to / listen for:

  • Different levels of ambition

  • Conflicting definitions of success (I want to build a huge company vs. a small business that runs as independent as possible)

• What is your biggest fear about the venture?

  • Personal, professional and company-oriented

  Pay attention to / listen for:

  • Fears that conflict with other definitions of success or expected sacrifice (e.g. fear of loosing control over the company vs. getting massive amounts of VC funding)

2. Strengths, Weaknesses, and Work Style

• Strengths:

  • What are your superpowers and key skills?

  • How do you plan to contribute to the venture?

  Pay attention to / listen for:

  • Do the strengths match with the role?

  • Missing contributions you would expect

  • Are our strengths complementary

• Weaknesses:

  • What are your key areas for improvement?

  • How do you compensate for these weaknesses?

  Pay attention to / listen for:

  • Weaknesses that strongly conflict with the role

  • Weaknesses that you have a hard time dealing with

  • Lack of self-reflection

  • Poor compensation techniques

• Work Style:

  • How many hours per week are you willing to work?

  • How much vacation do you need?

  • What work environment and culture suit you best?

  • How do you prefer to communicate?

  • How flexible are work times?

  • What are absolute red-flags for you in a working relationship?

  Pay attention to / listen for:

  • Remote vs. Office policy

  • Is “full-time” 40h or 80h a week?

  • Is everyone flexible enough to make a flexible work schedule work?

  • Can we make the way of working work with our preferred communication style? (e.g. calls and meetings don’t work with asynchronous remote teams)

• Conflict and Stress:

  • How do you handle conflict?

  • How do you cope with stress and burnout?

  Pay attention to / listen for:

  • Personal preferences. Awareness goes a long way on this one.

3. Roles and Responsibilities

• Preferred Roles:

  • What role do you see yourself playing now and in 2+ years?

  • How would you handle changes to your role (e.g., hiring above you)?

  Pay attention to / listen for:

  • What-if-scenarios that need to be addressed e.g. if hiring above is a dealbreaker, what will you do when it happens?

  • Misaligned expectations

• Key Skills and Passion Areas:

  • Rank your skills in key areas and indicate your passion level. (Scale 1-5)

    • Sales

    • Marketing

    • Product Strategy

    • Design

    • Engineering

    • Operations

    • Fundraising

    • Leadership

    • Company Building

    • Recruiting

    • Legal

    • any specific skill central to your venture

  • Who is responsible for what?

  • Where do you see skill and / or passion gaps?

  Pay attention to / listen for:

  • Lack of passion for topics you expect a person to own.

  • Lack of skill across the entire team.

  • Mismatch of role and skill & passion

• Decision-Making:

  • How should day-to-day and major decisions be made? How do you handle non-unanimous decisions?

  • What role do you expect in executive hiring, firing, or equity splits. ?

  Pay attention to / listen for:

  • Conflicts of control vs. autonomy: “I want to sign-off on any decision that is being made”, “Everybody is fully responsible for their assigned domains. No interference.”

  • Be specific on how you handle disagreement: e.g. majority vote, tie breaker and veto rights.

4. Financial Expectations and Constraints

• Fair Market Salary:

  • What would you consider fair compensation?

  • What is the minimum salary you need and for how long?

  Pay attention to / listen for:

  • Is this close to the market value? Is the compensation “fair” in comparison?

  • Is it realistic that you will be able to pay that compensation?

• Personal Financial Commitment:

  • Would you invest your own money into the company?

  • What is your financial runway?

  Pay attention to / listen for:

  • Unrealistic expectations

  • Clearly communicate constraints and related timelines

• Funding Philosophy:

  • Bootstrapped vs. venture-funded?

  • What level of funding do you think is ideal?

  Pay attention to / listen for:

  • Conflicting philosophies

• Equity and Exit:

  • What is your philosophy on founder equity splits?

  • For how long are you committed to this company (Founders Vesting)?

  • Under what conditions would you sell the company?

  • How do we handle if a co-founder can’t keep his original commitment?

  Pay attention to / listen for:

  • Conflicting equity expectations

  • Founders vesting

  • Good Leaver / Bad Leaver agreements

  • Exit expectations

5. Team Dynamics and Culture

• Ideal Team Culture:

  • What would make you proud of the company’s culture?

  Pay attention to / listen for:

  • Common set of values / Conflicting values

• Team Management:

  • What is your approach to recruiting, retaining, and managing talent?

  Pay attention to / listen for:

  • Common set of values / Conflicting values

• Work-Life Balance:

  • How will you balance personal and professional priorities?

  Pay attention to / listen for:

  • Unexamined prioritization

  • Different prioritization within a founders’ team can lead to friction

6. Co-Founder Relationship

• Support Expectations:

  • What do you need from your co-founder(s)?

  • How do you plan to support your co-founder(s)?

  Pay attention to / listen for:

  • Expectations that go beyond the mere role fulfillment

  • Clarity of expectations

  • Balance: Can we offer the support that is needed?

• Conflict Resolution:

  • How would you resolve personal conflicts?

  • What is your approach to a potential “startup divorce” scenario?

  Pay attention to / listen for:

  • Be meticulous on the divorce scenario even if you think it is not likely.

• Third Co-Founders or Partners:

  • How would you handle bringing in additional co-founders or investors?

  Pay attention to / listen for:

  • Veto and majority clauses

7. Execution and Alignment

• Short-Term and Long-Term Goals:

  • What are your goals for the next 6 months, 2 years, and beyond?

  Pay attention to / listen for:

  • Different levels of ambition and commitment

  • Different target pictures

• Barriers and Risks:

  • What challenges are you most concerned about?

  • What is your plan to mitigate these risks?

  Pay attention to / listen for:

  • Naive assumptions as clear signs that you haven’t thought things through.

• Alignment and accountability:

  • How do you expect to align with each other?

  • How do you hold each other accountable?

  Pay attention to / listen for:

  • Clear expectations e.g. how decisions are documented

  • There is no such thing as “too much accountability”

  • Preferred ways of follow-up and communication

These discussions won’t be easy, but they save you a lot of trouble, time and effort down the road. A lot of topics will also save you time with your legal counsel regarding co-founder agreements and other shareholder contracts. I know for sure that these questions would have saved me tons of money.

Want to make sure someone saves tons of money, too? Share it!

Share

Sources:

Gorman, M., & Sahlman, W. A. (1989). What do venture capitalists do?. Journal of business venturing, 4(4), 231-248. Chicago

I’m not a first-time founder. So, the common challenges of this rodeo are not new to me. But recently, I stumbled upon issues I wasn’t fully aware of until then, and I hardly heard people talk about them.

I was part of the “Euerzuhause” venture, which we sadly decided to close down by the end of the year. We promised people planning to build a house that we would match them with the best construction company and guide them through the entire process. We wanted to simplify the journey to home ownership. The construction companies paid us for leads and signed deals, and we actually made six-figure revenue with that. Unfortunately, our business model failed nevertheless, so we closed things down.

Failure is always overdetermined and many factors are out of our control. So it would be foolish to point to any specific learning and declare it the one reason for failure. The German housing market completely broke down in the past years due to increased material costs and mortgage rates. And there were probably uncountable little mistakes that potentially add up, but don’t make or break a business.

Nevertheless, some mistakes are specific lessons or insights I will take into my future endeavors. This is also my way of processing things to ensure that I learn from failure.

So in the hope that some people might find them helpful and learn from my expensive mistakes, here they are:

Traction does not equal product market fit

Making revenue with a product that doesn’t have a product market fit is possible. This seems contradictory - revenue is widely regarded as the indicator that cures all ills. If you have a product that gets customers to open their wallets, you have struck gold, haven’t you?

Not necessarily. Look at these cases:

• You are selling 1$ for 50 cents. In other words, you have customer acquisition costs exceeding your margins and customer lifetime value. Until you can adjust your product and marketing to a level with positive unit economics, your revenue numbers can lead you astray. Optimizations and scale effects help to improve the numbers but might not be enough to tip the scale in your favor. We never reached a favorable ratio of cost per lead to revenue per lead. The bet that scale will eventually fix this issue is a risky one.

• You sell based on promises. If these promises are being kept, is not immediately visible in revenue but can take up to years - especially with business models that rely on yearly SaaS subscriptions. I have seen mainly the “first-movers” develop a close bond with founders and sales representatives and sufficient convictions to pay for disappointing products for 2-3 years. But even the most loyal customers will eventually churn if you cannot keep the promises.
  Sales overpromising is very common - and honestly, it’s not just negative. You could even see this as solid evidence that a customer is willing to pay for a feature or the solution to a problem. But you need to be able to deliver within a reasonable time frame.
  We promised our customers (contractors) better lead quality than competitors. But to follow up on our promise, we filtered and pre-selected our users to an extent where it was no longer a profitable business case for us.

Just because there is a problem doesn’t mean people are looking for a solution.

So, to give you some specific context about my last venture:
Signing a building contractor is a precarious decision. The private house builder lacks the knowledge to assess the contractor's quality, and statistics and experience show that the likelihood that things will go wrong is concerningly high.

Billions of damages accrue yearly due to incompetent or fraudulent contractors, often sending the trusting customers into bankruptcy. Approximately 10-12% of the total industry revenue is fixing defects. This is no secret. Everybody is aware of the risks and the likelihood.

So, the assumption was people would gladly use our product to find the right construction companies. Especially since we did it free of charge and only charged the construction companies for the lead,

Unfortunately, we were ignorant of the actual behavior of customers who look for contractors. As we found out too late, they look for local contractors that they find likable and trustworthy and who seem okay with the budget constraints. Positive references are a plus but not necessary. 🤯 Yes. Trusting a stranger with hundreds of thousands of euros from a debt you plan to repay in the next 30 years primarily depends on the stranger’s likeability. No wonder this is a paradise for conmen.

These poor heuristics lead to the selection of the wrong contractor. But only very few people are looking for alternatives.

So, despite the awareness that selecting the wrong construction partner can cause financial ruin, only an insignificant number of users were looking for a solution.

I even had one customer researching the contractors' credit scores to deliberately choose a contractor with poor credit scores. It seems absurd, but the complexity of the product (building a house) seems to exceed the mental capacity to such a degree that users prefer to ultimately simplify the decision to a dysfunctional level.

When running the post-mortem on the venture, I could trace back the issue to a firmly held assumption (most people are looking for guidance on the selection) validated by poorly conducted customer interviews. When it comes to your initial research, avoid these blunders. If you didn’t research it yourself and it is poorly documented, immediately invest in validating these assumptions yourself.

Neither product problems nor business problems are customer problems.

At its core, a business aims to create customer value by solving problems or satisfying needs. No news here. It is easy to forget that in the day to day to work. Not intentionally, but simply because we are often distant from the customer. We try to empathize and hypothesize about their motives. But usually, we are not our own customers. What’s even worse: We can’t control our customers. We can’t tell them what to do.

When the numbers don’t add up, we reactively turn away from the customer problem and focus on product and business problems instead. At least we control these!

So, you start tweaking the site, running A-B tests, changing calls to actions, and adding features. You change up processes and policies like pricing and customer support and introduce new tools.

But all those activities failed to show results. How? Experts promised us that this would work! We used all the plays from their playbook: Conversion hacks, process automation, and funnel magic. And engagement rose as a result. But the one line we needed to move (Revenue) was the one line that didn’t move at all.

We realized, potentially too late, that the one service we intended to earn money with (referring construction companies) was mostly worthless to the customer. We were so busy optimizing our business processes and products that we failed to check in with the customer to truly understand their problem. Instead, we changed the design, tried different copy, and bundled the product with additional benefits.

We were convinced that optimization would do the trick when we should have realized the need to pivot. In our last months, we actually pulled off a pivot by focusing more on guiding users through the building process. We hit gold as customers engaged very well with that but it was too loosely coupled if not completely independent from our actual business model. The final decision to then switch-up the business model towards personal guidance and consulting, also meant that this business would not be as scalable as we needed it to be.

Some smaller lessons

Previous learnings I was able to confirm include:

• Never blindly trust self-proclaimed experts. Just because some agency proclaims to be an expert in PR, social media, SEO, or whatever doesn’t prove anything.

• Ownership is an essential incentive for entrepreneurs. It is impossible to drive real entrepreneurs if they are not the majority shareholder in a pre-PMF venture.

• Hire for and create a culture of ambitious amateurs. Ambitious amateurs are people who face a lack of abilities and knowledge, not just with a growth mindset but with vigorous learning and development. You need to be a jack of all trades in an early-stage startup.

• Clear expectations make healthy relationships.

• About fund-raising: Start way earlier than you need to. Building the right relationships takes time and so do the negotiations. But if you are about to run

  out of cash, it puts you in a poor position for the negotiation.

• Product market fit is not binary. It’s on a scale and multidimensional.

One of the evergreen topics in product management remains product discovery. And probably for a good reason: Most product investments fail because they should not have been made in the first place. Either there never was a problem to begin with or the solution didn’t solve the problem.

But what makes product discovery so hard?

To begin with, recruiting customers for the research is not always easy. In one case, I only got sufficient customers to take time for in-depth customer interviews by giving out 75€ Amazon vouchers. It was always easier to talk to B2B customers as they tend to be more vested into the development of the products they use.

Nevertheless, a product manager’s schedule can be demanding, and carving out time for any proactive activities is sometimes a challenge. In these times and can simply feel overwhelming to do discovery right and half-assing might feel like a waste of time.

But any discovery is better than no discovery. And very often we over-estimate the amount of discovery necessary.

So let’s start with the basics.

The goal of discovery is to reduce uncertainty

When discussing discovery, we sometimes forget that the goal of discovery is to decrease uncertainty. There are several takeaways from that. First, it’s about reducing uncertainty. You will probably never eradicate uncertainty. Second, reducing uncertainty has value, while discovery activities create costs. These costs include the time invested in research activities and the costs of delay for not delivering a potential solution earlier.

This frame of mind helps you better prioritize what you want to discover. Product decisions are always like bets, meaning sometimes you lose. That’s part of the game. But some bets are so small that you should be sure not to over-invest to improve the odds.

If it is worth improving the odds, ask, “what part of an idea are you most uncertain about?” Investing time in these creates better returns than re-confirming things that can be considered best practices.

The challenge remains to correctly make the right assumptions about risks. You probably can’t continuously challenge the most underlying

Factors influencing the amount of discovery necessary

There are several other factors influencing the amount of discovery you actually need.

1. How certain are you about your ideal customer profile

   Do you have a clear picture of your ideal customer? Maybe you even have quantitative evidence that a specific customer segment is especially valuable to your company e.g. as heavy users and loyal customers. Narrowing down the group of people whose problems and opinions really matter will increase the likelihood of representative results tremendously. If you want to create products for Botswanian fishermen, you should not ask American hairdressers for their opinion. If you target exclusively whales (e.g. fortune 500 companies) just gaining a single raving fan in that camp can be sufficient to continue. On the contrary, if your target audience is women between 20 - 50 years, you will probably need quite a while to get representative results.

2. How much variance is expected in an answer?
   The easiest research questions are binary - Yes / No. E.g. simple a UX test where you simply test if a user understands how to use a function. But also when it comes to discovering if customers face specific problems, e.g. do you export this data to another software? This simple question might help you to identify interfaces to other software as a promising opportunity. Even with one sample, according to the "single sample majority interference, we can assume that in the binary case the likelihood that a single sample represent the majority is already at 75%!

   
   If you are asking for assessments in an ordinal scale (e.g. NPS, CES) or even ratio scale (revenue, costs), theoretically, the answers can vary greatly. But the probability that the true median is within the range of responses of 5 samples is already at 93.75%. Let’s say you want to explore if you should automate the creation of delivery forms and you ask five customers how much time they spend daily creating these forms. The answers are 20, 25, 30, 32, and 40 minutes. Then we can be quite certain that the true median is somewhere between 20 and 40 minutes. This insight is only helpful if we observe a small spread. If the answer insight is “somewhere between 0 and 240 minutes” we might have to dig deeper. If the answers cluster quite closely within an attractive range, then you are good to go.

3. How quickly do you start to see patterns?

   Even in the case of very open questions (like my favorite UX research question “Tell me about what about your work annoys you most”) where you can possibly get an infinite amount of different answers, you might be surprised how quickly you hear the same answers over and over again. When I talked to fleet managers for FINN, most of them where complaining about being the “middle-men” between drivers and fleet provider. When I talked to people who were building houses for EuerZuhause, people had all kind of different challenges but the majority was desperately seeking for guidance. Sometimes it takes a few more interviews, but I feel like like it is usually not more than 10 until you start to see commonalities.

Quality and depth trumps volume

As with lot of trending topics most discovery activities I come across are shallow and of poor quality. When it comes to quality: Your research questions should not be suggestive, social desirable, platitudes, or ask for intentions.

Suggestive is anything that frames the customer towards an answer. Asking “Is X a good idea?” already frames X as good.

Social desirability is everything that is deemed to be morally good these days. “Is sustainability important for you” will more likely than not be answered with “yes” regardless if that person actually puts their money where their mouth is.

Platitudes are questions like “Are you interested in saving money?”, “Do you want to make more money?”, “Do you want to save time?”, “Is quality important for you”. Asked in these general terms you are likely to get zero insight from these question.

Lastly, asking for intentions is worthless. Never aks what people would do. If they would buy a product or would find certain features nice. These intentions are as reliable as new year resolutions. Ask for specific behaviors in the present or past instead.

When it comes to depth, sitting down with a single customer for an hour will give you a better idea of the motivations and reasons for their behavior. An email survey can provide lots of answers in a short time. But they lack depth. You rarely have the opportunity to really dig deep e.g. as to why a customer finds a specific feature useful or not.

Interview and automate

I strongly advise to use in depth customer interviews when creating a new product or if your are looking for product market fit. If your product is up and running and doing fine, you shouldn’t completely drop the interviews either. But the traction allows you to facilitate a more constant stream of feedback in the form of in product questionnaires, service tickets and analytics. All of these can provide evidence to confirm or disconfirm new ideas.

And best of all - you can automate them.

All things considered just a single good customer interview every week or two and some reliable sources for customer feedback can significantly decrease the uncertainty of your product investments.

In “The Dip” Seth Godin describes the all-to-common valley of despair that most projects, ventures or other creative endeavors experience: The lack of results after initial quick progress that leaves you frustrated and tempted to quit. Eventually, with continuing effort, the breakthrough is there, and on the 1001th iteration, just like Edison and his lightbulb, your product will work as you envisioned it.

The common notion is that these lows are simply part of the journey. The entrepreneurial roller coaster. The divine test to separate the winners from the losers. You just have to keep chipping away and success will come, they say.

But “Never quit” is a nice rallying call but poor business advice.

There are plenty of well-documented cases of the sunk cost fallacy that led enterprises to despair by continuing to invest in hopeless business cases. The agile movement is based on the premise that we sometimes must admit we have been wrong and change course. There are excellent reasons to call it quits and abandon a business, project or idea when it is not delivering the intended results. So after the low that resembles the “dip” there is no up-swing. There is a cliff. The end.

Now, in hindsight, it is easy to call out the winners. But if you are in that valley yourself, it is hard to determine if it is just a dip or a cliff. They look and feel the same at the beginning.

So let’s say you launched a new product that fails to show traction despite all your discovery efforts. That happens to the best of us. Should you drop the product or continue investing in it to improve it?

This is a common dilemma not only in startups but also in every product team.

There is no clear-cut recipe for these decisions, but these questions helped me the most:

Are customers willing to engage with you?

Customers are the ultimate judges when it comes to products and enterprises. Their willingness to engage with you is a great canary in the mine.

• Dip: Key stakeholders and customers are responsive, actively engage with you and your product, and are willing to provide feedback. You have good customer relationships.

• Cliff: Customers are disengaged and hardly respond to your efforts to get their feedback. The customer relationships are strained.

Is this impacted by the current market conditions?

We are all dependent on higher powers to some extent. Markets can follow trends and cycles you as an individual are powerless to impact but that you can sometimes use in your favor.

• Dip: Market conditions are temporarily poor but improving, indicating that your product could catch on if you persist.

• Cliff: Market trends are moving away from your product's value proposition, and external conditions are increasingly unfavorable.

Do you see a positive change, no matter how small?

The analogy of “chipping away” at a problem is helpful here. The tree is not falling yet, but can you see chips flying? Or are you banging your head against a wall?

• Dip: There are positive signs of incremental progress, such as improved KPIs, customer feedback, or small but consistent wins.

• Cliff: Efforts lead to stagnation or regression, with no signs of positive momentum despite ongoing investments.

Can you pinpoint the causes or issues?

Every sensible problem-solving process presupposes a problem definition. If you fail to define the problem, you will fail to devise a solution.

• Dip: Feedback and data clearly indicate the issue and what causes the lack of results. Based on that, you have a clear idea of what to tackle.

• Cliff: Data and feedback is inconclusive. There are no apparent issues; most improvement ideas are based on hunches and guesses.

Do you have a plan for how to improve the situation?

If you can define the problem, do you have actionable plans to tackle it? Strategy “Hope” - doing nothing and hoping for the better - rarely works. At least you should have a set of solution hypotheses you can work on and the resources to do so.

• Dip: Resource expenditure is sustainable, with a clear plan for future growth and potential return on investment. You have many ideas and the time and resources to try them.

• Cliff: Resources are depleted rapidly with no clear path to recovery or success, signaling unsustainable investment. You run out of ideas, time, and resources.

Is this an essential part of your long-term strategy?

Some ideas have value even though their impact is not immediately measurable. Heck, this thing here, writing, generating content, is such a thing. This post won’t make me any money, but it supports my long-term goal of improving my craft. I guess most projects that you could define as R&D or other learning efforts fall into this category.

• Dip: The project aligns well with your long-term strategic goals and core mission. This might not have an impact now, but it complements your core competencies.

• Cliff: The project has drifted from strategic priorities or core competencies, leading to doubts about its long-term viability or value.

Do experts and advisors agree with your view?

Sometimes, we are too far into the woods to realize we can’t see the forest for the trees. Plus, we are also prone to the confirmation bias that makes us ignore disconfirming evidence that we should stop our endeavor while making us narrowly focused on the tiniest confirming evidence. Getting an outside view is helpful to check yourself.

• Dip: External advisors or mentors with industry experience believe in the project’s potential and recommend that you persevere.

• Cliff: External feedback is consistently negative or suggests that the project is unlikely to succeed, advising you to withdraw.
  (Note: Be ware of you confirmation bias. You might actively look for those who tend to agree with you).

Are you still passionate about the idea?

It’s not objective, but there is a case to be made that you should no longer stick to a project you are no longer passionate about. Money might be a great motivator, but the stresses of a project that feels hopeless and exhausting should be at least considered.

• Dip: Despite the setback, you are still passionate about the topic. You firmly believe you can make this thing work.

• Cliff: The fire is out and when you think about the project, all you feel is “stress”. You lost hope that this will work.

These are by no means “conditio sine qua non” - one or two questions may suggest that it is a cliff, and you still could have plenty of reasons to persevere. However, these questions helped me persevere in some cases and helped me quit in others.

“When we treat man as he is we make him worse than he is.
When we treat him as if he already was what he potentially could be
We make him what he should be.”

Johann Wolfgang von Goethe

I often read this quote as it profoundly resonates with me and represents my approach, especially toward young people. I tend to see more potential in interns or young colleagues than other colleagues do. It fits neatly with my idea that we are always “becoming creatures,” given that we have the mindset that people can learn and develop and are not static in their personality and characteristics.

I made the deduction that the same holds true in the organizational context. That we should act like the organization already is what it could be to make it what it should be.

I was wrong about that.

You want to change the organization for the better and towards the ideal of a flexible and high-performing meritocratic organization that it claims it is or wants to be. Yet on every push in that direction, that same organization seems to slap you in the face: Your promotion is blocked, budgets are cut and doors are being slammed.

But why? You followed all the change and management advice that is deemed ideal. You started with “Why,” you were vulnerable and caring with sufficient candor, and you thought big while also getting the details right - the numbers were simply off the chart. Then why didn’t the organization change for the better, and why did you not get rewarded?

The answer: You didn’t treat the organization and its members as they are.

I, too, was an idealist and clung to how things should be according to my rational worldview. I lacked the maturity to be comfortable with a paradox: I must treat people and organizations as they are and what they can be simultaneously. Holding these contradicting ideas simultaneously also leads to partially contradicting behavior.

I’ll give you an easy-to-follow example. We can all agree that an organization should be meritocratic, meaning people are rewarded through money, recognition, and promotion for their merit. The directive is clear if we look at the organization and man for what it can be: Do the best work possible, and the organization will reward you.

Yet, when you look at the organization you work for, is this the case? Do you firmly believe that those who do the best job are promoted? Probably not.

Schmoozing, likability, personal networks, and intelligent political maneuvering are indispensable parts of organizational life. Following the meritocratic idea, spending time on these things is a waste. However, lack of acknowledgment of “politics” in an organization doesn’t lessen its impact. That’s why you see persons who excel at these things move up the career ladder faster than you do.

It is an uncomfortable truth that to gain the power to improve things, you might need to take actions that conflict with your values and long-term intentions (assuming you aim towards that meritocracy).

You can reasonably argue that this behavior would be opportunistic because it probably is in the short term. If you follow through on your commitment, however, it is pragmatic. It allows you to solve the problems you are facing in a sensible way that suits the conditions that really exist now, rather than obeying fixed theories, ideas, or rules that stick to how things should be - but are not.

I can fully understand if the idea of Machiavellian schemes to improve things irritates you. But it is little use criticizing the excesses of terrible leaders and organizations but then being too squeamish to engage with and win power yourself.

Fool and foolish behavior have a terrible reputation. Being called a fool is commonly an insult. Foolish is seen as the opposite of witty or intelligent.

However, the fool played an essential role in the era of aristocrats. The fool, or as Kets de Vries likes to differentiate the clown from the fool, the sage-fool wasn’t a mere entertainer stumbling over his feet. The sage-fool had the unique privilege of speaking truth to power. Germans have even a word for it “Narrenfreiheit” which roughly translates to “freedom of the fool”.

Aristocrats weren’t exactly fostering an open feedback culture these days. Criticizing or correcting your king and queen could lead to arrest or even your execution. Thailand and Saudi Arabia actually still have such laws in place. However, the fool was allowed to speak truth to power through humor and satire. With exaggeration and tongue-in-cheek remarks, the fool puts up a mirror to the king’s face and closes the gap between the royal court’s ivory tower and the hardships of the commoners.

In this role, the fool is a counterbalance to the hubris of the kings and queens who might have lost touch with reality and whose leadership pathology needs to be kept in check.

Even though modern business organizations are less Draconian in their punishments, their leaders are also susceptible to leadership pathology: hubris, narcissism, paranoia, authoritarianism, isolated groupthink, scapegoating, and even ethical lapses.

And even though we like to think that especially new companies and leaders have developed in the past decade, I just recently spoke to someone from a successful start-up who openly admitted that it was a known fact that disagreeing with the C-level executive of his company usually meant the end of that person’s career progression. Additionally, the executive's claims on public podcast appearances were far-fetched and not even close to the reality the employees experienced in their day-to-day work.

These pathologies not only harm the leader's effectiveness but also negatively impact the organization's culture, productivity, and overall health. An “organizational-fool” can counterbalance these tendencies, helping keep leaders grounded and connected to reality. And even though the sage-fool may be a role that can be temporarily taken by any person, similar to people playing the devil’s advocate, it is much more likely that only a few persons have the guts and the trust of the leadership team to assume that role.

Through humor and satire, they can communicate difficult truths and offer critical feedback that others might hesitate to provide. By exposing the irrational or exaggerated aspects of leadership decisions, the fool helps prevent groupthink and fosters a culture where open communication and critical thinking are encouraged. Additionally, humor can defuse tensions and provide emotional catharsis. This helps maintain a balanced and positive organizational environment, reducing the likelihood of destructive conflicts or decisions driven by unchecked emotions.

We are well-advised to make room for such foolish behaviors in our teams. This can even be initiated by leaders, who can laugh at themselves and openly do so. A little meme can go a long way.

Inspired by Manfred Kets de Vries - "THE ORGANISATIONAL FOOL: BALANCING A LEADER'S HUBRIS"

Subscribe now

In product and especially entrepreneurship, I learned to become increasingly comfortable with a high level of ambiguity. If ambiguity were a color, it would be grey. This miraculous color with infinite shades is neither black nor white. In my career, I've faced countless decisions where no amount of research and testing separated the options. Evidence and experts were pointing in different directions. The data was inconclusive.

Nevertheless, you need to be decisive and confident. Being ignorant would certainly be one way to cope. Ignoring alternatives in the first place or disconfirming evidence for your favorite solution, one can easily convince themselves that there is only one solution. The upside of this coping mechanism is that you will exude confidence about the decision. And even false confidence is, unfortunately, often more appreciated by management than any expressions of doubt.

The trick is to be open-minded and assertive simultaneously—you should hold and explore conflicting possibilities in your mind while moving fluidly toward whatever you think is most likely true based on what you know and learn. It goes along the way of "strong opinions. loosely held".

Barrack Obama described it nicely:

"People used to ask me, Why was I calm during the presidency? In addition to being from Hawaii, which really helped (we're just chill)," he joked, "part of the reason is I set up processes. So by the time I made a decision, I might not get the outcome I wanted, but it might be a 51-49 decision or a 60-40 decision, but I can say I heard all the voices involved -- gotten all the info, seen all the perspectives -- so when I made a decision, I was making it as well as anybody could make it."

The truth is every tough decision comes down to a probability, and certainty is an impossibility — which can leave you encumbered by the sense that you can never get it quite right. Instead of obsessing about the idea of data-driven decision-making, your process should include analyzing available data, but you should also be able to proceed when data seems inconclusive. Crippled by doubt, I have experienced PMs falling into a slump characterized by a backlog of fragmented marginal improvements and a complete absence of any big bets.

Test your understanding of the matter with the information you can get. But don't underestimate the value of quick decisions and the cost of hesitation. Being decisive in the face of contradictions has its worth.

Subscribe now

So if you are only 5’4” (160cm) you should not try to become a basketball player, as taller people will likely be better than you with a fraction of effort.

This analogy represents the ruling trend of a strength-focused approach to skill acquisition. Proponents of this approach argue that one should primarily focus on what one is naturally good at to leverage “god-given” talents. That way, one's return on learning investment might push one into the world's top class. On the other hand, focusing on one's natural weaknesses would get you to a mediocre level at best. There is a German saying that you can’t turn a plowhorse into a racehorse.

For most professions, skill is usually not measurable on a single scale

This line of thought also assumes that “skill” and its utilization depend on a narrow scale. E.g., a golf player’s skill to hit a ball where he intends to hit it will determine if he is a good player. The same is true for mastering an instrument. These professions also have in common that the top that can make a good living is very small. Only a tiny fraction of piano enthusiasts will become concert pianists who can make a comfortable living. The great majority will have to downgrade their aspirations to a hobby. The same goes for most athletic endeavors.

Most knowledge worker professions, however, are less unidimensional. What makes a great leader or manager? That’s a question that inspired entire libraries of books. It is not a single skill but a combination of countless skills determining your effectiveness.

Instead of a single skill, we need to think of skill stacks and the combination of skills. This doesn’t mean that deep expertise in a single domain is worthless, but on a pragmatic level, I have found it to have diminishing returns in most contexts. At the same time, smart skill stacking can deliver exponential returns.

People like me, who have trouble identifying a single passion, can use their curiosity to strive for an extraordinary combination of skills instead of becoming extraordinary in a single skill.

Skill is context-dependent

In addition to that, effectiveness is highly dependent on context. A start-up requires different management and leadership approaches than a large corporation. Certain skills do not transfer well between different company cultures; others do. This insight is a warning and encouragement at the same time. We might be over-confident in our skills if we don’t realize that our effectiveness has been increased by the context in the past. E.g., colleagues that perfectly filled your deficiencies or that you have been welcomed to fill a void such as a lack of leadership. Without these colleagues and a request to align with current leaders, you might find yourself ineffective after all.

But this is also an encouragement to find a different pot in case you find you can’t bloom in your current one.

Skill doesn’t follow a Gaussian distribution

When discussing skill and skill distribution, we pretend that skill follows a Gaussian distribution. This means most people are okay; half are poorer than that, and half are better than that.

I think skill is more often distributed according to a power law distribution. That means the majority, and that is up to 80%, sucks at a skill. You might not perceive it that way as you are in a bubble of peers with similar interests and motivations. My rudimentary knowledge of HTML, CSS and javascript doesn’t make me an expert developer and even an equal to the developers I work with daily. But 80% of people have never even tried to touch code.

Sadly, most people are not interested in getting better at something, so they don’t even try. No one was born a master. Taking a few steps on the mastery journey will be sufficient to get you in front of the pack, that is, most people. You probably won’t be a world-class and recognized expert, but that’s okay. The newly acquired skills can open up new opportunities either way.

Tackle bottlenecks or multipliers, regardless of your talents

It’s okay to have weaknesses. And it is fair to say that you should not tackle a weakness if you can compensate or circumvent it. If you have no nag for coding, but there is absolutely no need for you to do so, why go at it?

If your weakness is an absolute bottleneck, it’s a different game.
For example, I am not naturally structured. However, I found that my lack of structure hampered my productivity and my ability to delegate and communicate. I worked hard to become more structured, which paid off tremendously. Even though I still have room to grow, I am past the point where it hurts my effectiveness.

The same goes for multipliers. Sometimes, skill gaps don’t hurt, but closing them would have an outsized return on investment. Technical experts who add people management to their skill sets often experience outsized returns through their career progression.

The often-cited advice, “Don’t bother working on your weaknesses; you will never be great at them no matter how much work you put in them,” is true in essence but poor advice. You might not become great at it, but you will be good enough. Good enough so it does not hamper your effectiveness.

In defense of deep expertise

So when skills become more valuable by stacking them, and you can get into the top 10% in relatively short periods of time, is deep expertise still valuable? Is it really worth the effort to inch towards the top 1%, top 0,1%, or even further when facing diminishing returns?

I believe it is. Regardless of the craft, people at the pinnacle get paid handsomely and often find more meaning in their work. Achieving mastery is fulfilling personally and professionally. Sticking it out and truly investing the work necessary, even to get close to mastery, is extremely hard - so most people give up. That’s why true experts are so rare.

So, if you want to add that to your mix, you need to make sure that you have sufficient love for the subject to go all the way.

Subscribe now

‘42’ - this was the answer of the supercomputer Deep Thought, who was thinking deeply about the meaning of life, the universe, and everything else for seven and a half million years in Douglas Adam’s cult novel “Hitchhikers Guide to the Galaxy”.

Needless to say, people were dumbfounded but had to admit that they couldn’t really tell what “everything else” actually entails. “So once you do know what the question actually is, you'll know what the answer means.”, Deep Thought explained. However, it didn’t possess the ability to come up with the question.

Despite its age, The Hitchhikers Guide to the Galaxy gives a profound idea of the human role in an AI-driven economy. Assuming there will be an oligopoly of providers who will remain in the battle for proficiency in delivering the best answers and outputs, your competitors will have access to the same AI tools that you have.

Hence, we face a completely new challenge. While we used to compete by giving better answers through the use of our human intelligence, we now see that artificial intelligence often comes up with better solutions in a fraction of the time. However, as we use essentially the same AI systems, how do we come up with better answers that set us apart from the competition?

Better prompt engineering could be a way to optimize the answers, but it is probably not enough to fully differentiate.

The only way to differentiate is it seems to ask different questions. Questions that contain essentially different assumptions. Based on the way large language models work and learn, these systems use facts as assumptions that are most common.

I’ll give you a concrete example.

When I asked ChatGPT if heat pumps are a climate-friendly way to heat your home, its answer was: “Yes, heat pumps are generally considered a climate-friendly way to heat homes, for several reasons (…)”. In summary it states:

In summary, when integrated into a system that prioritizes energy from renewable sources and with continued technological improvements, heat pumps represent a significantly climate-friendly option for heating (and cooling) homes.

In this case, ChatGPT hints towards a critical assumption: “(…)when integrated into a system that prioritizes renewable sources (…)”. But this is not always the case.

So let’s change that: “Assuming an energy system that is fully based on coal and taking into account the efficiency loss during the production and transportation of energy, are heat pumps a climate-friendly way to heat your home?”.

As a result, the answer changes.

While heat pumps are more efficient than traditional heating methods and reduce the total amount of coal burned, the scenario of an energy system fully based on coal diminishes the climate benefits of heat pumps compared to scenarios where the electricity mix includes lower-carbon or renewable sources. The specific calculations would depend on the exact efficiencies involved, but the fundamental issue remains: the high carbon footprint of coal as an energy source makes it challenging to classify heat pumps as "climate-friendly" under such conditions without broader systemic changes to reduce carbon emissions.

My goal is not to discuss heat pumps or their sensibility, but I want to use this as an illustration that asking “deeper” questions that fundamentally challenge common assumptions leads to different answers.

The challenge of core assumptions has always been integral to innovation and revolution. Communism challenged the idea and role of private property, a core requirement for capitalism. Einstein’s theory of relativity superseded the theory of mechanics that ruled theoretical physics and astronomy for 200 years. Space X challenged the assumption that rockets can’t be reused and changed the space transportation business.

On very different levels, the ability to question the status quo and to develop opinions about reality different from prevailing thoughts not only remains a unique human advantage but is also a key component to leveraging AI capabilities while differentiating from competitors.

What are the predictors for how much time monkeys spend grooming and delousing other monkeys? I would have assumed it depends on the monkey’s size and hair length. More hair needs more grooming. But it’s not. The best predictor for time spent delousing is the size of the tribe. The bigger the tribe, the busier the monkeys combing through each other’s fur.

This behavior makes sense when we consider grooming and delousing each other not as mere fur hygiene but as a primary way to foster relationships and - when push comes to shove - alliances. With size, the socio-hierarchical structure gains in complexity and dynamic, requiring more effort by each monkey to strengthen their position in these groups.

At the beginning of my career, I was convinced that politics is an organizational dysfunction. I saw politics as a game defined by pursuing selfish interests through unethical means such as coercion, deceit and lying. I also believed this was a game you could refuse to participate in, holding steadfast to my ideals of rationality and meritocracy. It still hurts me to admit - I was wrong.

On the upside, there are also positive types of political behavior. Volunteering for projects to gain more visibility and proponents for your next promotion can be considered political but is a win-win. Sucking up to a person you don’t like leaves a bad taste, but being friendly doesn’t hurt anybody. So politics isn’t all black and white.

At the core, political behavior is not about aggression and dishonesty but about building relationships. And no matter how often organizations pay lip service to meritocracy, large-scale studies show that personal feelings play a more important role in forming work relationships than is commonly acknowledged. It is even more important than evaluations of competence. We prefer to work with the lovable fool instead of the competent jerk.

And I would up this a notch: If your colleagues place you merely in the “meh - not much of an opinion section” of a likability scale, you might as well be a jerk. To oversimplify it: You can't expect any support if you have no relationship with that person. We are not different from the monkeys. If you haven’t groomed the silver-back, you are not on the team and left to fight for the scraps. We want to pretend this is not the case, but it is.

So, my first insight was that I needed to get rid of my childish and naive belief that it pays to be a good soldier and that doing the right thing would eventually prevail. Fairness is a core value of mine, but still, life is not fair.

Secondly, I needed to realize that as a manager of a team within a larger organization, managing those relationships is an essential part of my job. Refusing to play that game, as I framed it, equaled me not doing my job. And as a matter of fact, the entire team suffered because of it. Despite the objectively outstanding performance, I failed to get buy-in and the necessary resources. And I did so because I failed to build relationships with the right people.

Lesson learned: Politics is a law of nature, especially in large organizations where relationships don’t happen naturally through proximity. In these contexts, one must create proximity to build the relationships that will help you get things done.

As product managers, we love frameworks and checklists. However, it is important to understand that frameworks are not checklists. It is important to understand the difference between those two and the real purpose of a framework. Checklists are complete and prescriptive. Take the example of a pre-flight checklist. It should include all vitally important functions of the plane and give explicitly or implicitly clear instructions on how to test it. Another example would be the assembly instructions from a piece of furniture, which should tell you exactly what to do and, eventually, should lead to a fully assembled piece of furniture.

Checklists can be a tremendously powerful tool, especially regarding quality and consistency. However, checklists fail in complex environments. There, a step on the checklist might work only every other time.

The more fuzzy an environment or problem, the less likely it is that you will find a suitable checklist.

Frameworks, on the other hand, exist to frame an otherwise fuzzy problem, turning naturally ill-structured problems into structured ones. This is tremendously valuable for any management profession that needs to tackle complex issues. However, we need to keep a few things in mind:

1. Frameworks are always incomplete. A framework is always a simplified version of reality. As a consequence, no framework can claim to be always right. So, we should consider if the assumptions of certain frameworks are being met.

2. Frameworks frame (duh ?). That means we need to be careful when considering which framework we use as they might favor specific solutions, neglect or oversimplify certain factors, or they might be suitable for specific decision altitudes. For example, the business model canvas is great when it comes to developing a product from scratch with a new business model but becomes quickly useless when the business model is fixed, and the product needs to be optimized through marginal improvements. Another example would be the breakdown of cost and profit into its different types and drivers, as often used in consulting job interviews. This framework might be great for identifying optimization potential but falls short regarding innovation, especially disruptive ones.

3. Knowing the principles and theory behind frameworks lets you know when to adapt or ignore them. This seems to be tough to swallow regarding agile development methodologies, which are essentially frameworks. But understanding the intent and reason for, for example, Scrum meetings makes it sometimes obvious to identify when to disregard them or even Scrum altogether. Or, lo and behold, combine frameworks if you feel it helps you develop better solutions. Personally, I once introduced a heavy mix of Scrum and Basecamps Shape Up. On a product level, we prioritize on a theme level representing either one epic or a bundle of thematically related epics. This theme is being prioritized and fixed for 6-week cycles, and we were very strict about not altering the foundational priorities of topics that are already in development. The breakdown of themes into stories is then done in a Scrum manner. Stories are collected and prioritized in a backlog and pulled into our biweekly sprints, and we are honestly very quick to alter sprints whenever necessary. Most of these changes originate from inside the team or from new "insights" like having severe bugs in production, but are never triggered by a stakeholder's new feature request.

I find this differentiation worth mentioning because frameworks are treated like fanatic religious beliefs way too often. Many SCRUM practitioners and SAFe opponents are prone to overvalue their framework and become too rigid in their application. The same goes for debates around the superiority of growth loops vs. funnels. Sometimes, using different frameworks on the same problem can open up new perspectives on a challenge, mitigate each other's blind spots, and generate a more complete view of the problem. But we should always see them for what they truly are: Intellectual crutches. We use them to get a hold of intellectual ground we otherwise are overwhelmed and unable to stand on. However, over-relying on crutches deteriorates our capability to think critically and entices us to apply them more often than they are fit.

One of the long-lasting acronyms in product management is INVEST. Going back to the works of Bill Wake the acronym urges us to make sure that stories are independent, negotiable, valuable, estimable, small, and testable.

While in theory intuitive, the guideline practically presents quite often a dilemma. It is often difficult or impossible to reconcile independent and valuable with small. The trickery teams use to overcome this dilemma usually includes breaking down user stories into smaller ones and labeling them valuable by making up some sort of learning to be achieved.

And this approach is reasonable when assumptions are risky and especially the problem is poorly validated. We had such a challenge when we wanted to enable customers to invite drivers to the FINN Business portal. Some interviews indicated they were, but we all know that stated intentions do not necessarily match future actions. We therefore launched a simplified version of “invite a user” before developing a fully-blown user admin interface to test the fundamental value assumption. The stories were small and valuable as we were confident that we would see a change in behavior in the form of driver invites.

On a different occasion, the challenge was another one. We observed that customers passed delivery and driver information as comments upon checkout. This essentially delegated these administrative tasks to our customer success managers, even though our customers could do it themselves after the checkout. So we had a UX challenge at hand where we wanted to see the outcome (change in customer behavior) that more customers enter this information themselves. We decided to design an express checkout that would allow the customer to capture that information as part of the checkout (more proximity = better adoption) with as little friction as possible. Pretty straightforward.

But during refinement, we got stuck in sizing discussions. The team had a strong urge to cut the functional scope and even the design requirements in order to split the story into much smaller ones. Just like it worked for our “invite user feature”.

But this was different. The well-validated problem we tried to solve was a UX problem. The degree of behavior change we will achieve is therefore dependent on the quality of the UX flow we build. The solution was feasible, the required additional effort was reasonable, the alternative intolerable.

One counter-argument was that we would maximize learning by splitting this one feature into several smaller iterations. But I disagreed. If we see poor results from the first iteration, we remain confident that the next iteration improve the results. If we get good results on the first iteration, we remain convinced that we can get even better results with the second iteration. So the second iteration is not really debatable and already defined.

So given that we want to maximize the value by changing observable customer behavior (customers enter the information themselves), I was glad to ignore “small” for the sake of value. The key difference here was the problem validation. The problem was well-validated. We saw countless customers passing order information through the comment field. So there already is evidence that the user wants to pass this information. Even the solution was highly inspired by existing solutions from our B2C department. So the risk was minimal especially compared to the investment.

I am a fan of INVEST and iterative development. But sometimes you should also be fine to push something bigger if you know it is the right thing to do.

Why this matters

There will be times when you have to give bad news such as layoffs or lost promotions. Leading these conversations with grace is an admired leadership quality.

In a nutshell:

• Get to the point and get there fast. You might feel the urge to procrastinate these conversations, but beating around the bushes won’t help.

• Pause to let the message sink in before you present further information

• Offer understanding and fully take responsibility by explaining the decision and the tradeoffs you are facing. Don’t expect agreement though.

• Don’t blame others for the decision. As a leader, you represent the organization, and you accepted that role when you took your job.

• Show empathy for the emotions the other is going through. Err on the side of validating these emotions instead of downplaying them.

• Close with an invitation for conversation or support, and follow through on it.

Pro-Tip:

Especially with layoffs: Get in contact with the persons. 1 -2 months later for a lunch or a (digital) coffee chat. This shows that you care and can build relationships for the long-term.

There is something that makes product management hard and good product managers rare. Jason Knight brilliantly summarized it in this tweet. Context-switching and zoom level.

Product management is a uniquely hard job. Why?

1 - Context-switching

You're bouncing between discussions with devs, marketing, customers & leadership, all day every day

2 - Zoom level

You're zooming between the bluest of blue sky visions & the smallest details constantly

— Jason Knight (@onejasonknight) February 22, 2023

It is unfortunately something that is hard to coach or teach. While neuroscientists generally agree with the notion that you pay a high price for constantly switching context and that the sheer volume of work can drive out any creativity that you need for high-level thinking, I've found a few handy tools in their toolbox.

Ruthlessly triage all daily issues with the help of heuristics

Paradoxically, the first advice about context switching and deep-diving is actually checking if this is something you should dive into.

Especially in high-growth companies you need to get used to the fact that a lot of things are constantly breaking. If you try to solve or even understand all issues to the fullest extent you will run out of mental capacity in no time. The solution for this is triaging.

The word "Triage" goes back to the Napoleonic wars, where field doctors had to make decisions on the spot about which wounded soldiers to patch and treat, and which soldiers to leave to their fatal destiny. While the comparison to life and death decisions seems overly dramatic, it makes my point that less significant decisions can be made through triaging as well.

To triage issues, I quickly check three things:

1. Does it move the needle?
   This can be both ways. Does a bug impact my product to the extent that it will stop working? Or will it be only a minor annoyance? For an opportunity: Will this significantly impact goal achievement or is this mere cosmetics?

2. Am I the best and/or only person who can take care of this?
   Especially as I occasionally tend to the random act of heroism, am I honestly the best or only person to handle this? It is absolutely fair to ask colleagues to take over or step up if possible.

3. Is this urgent?
   Urgent is sometimes misrepresented as things that have an immediate impact. But urgency should also include the long-term impact of delaying something right now. From that perspective, technical debt or architectural challenges become urgent before it causes immediate issues, in the moment we realize that postponing that decision will make the solution much more expensive in the future. The same goes for opportunities. Is there only a little time window when the iron is hot?

With an increasing volume of issues crying for my attention the demand to tick every box with "yes" rises as well.

Take smart notes and dump your brain into tools

In a set of interesting studies, the Lithuanian-Soviet psychologist Bluma Zeigarnik found that interrupted or unfinished tasks continue to take up mental space, even when switching contexts. The good thing is, that this effect helps us to quickly recall the "unfinished" tasks and the context. The bad thing: It takes up mental space and, similar to software running in the background that slows your computer, also hinders you from bringing your A-game to the next topic. Personally, I noticed that the level of lingering projects and to-dos can snowball into an avalanche of stress.

The tools that help me to avoid a constant build-up are my task manager (Todoist) and my notes system (Evernote & Paper personally, Confluence and Google Docs in the collaborative company setting). The actual software of your choice doesn't really matter. It is much more important to nurture the habit of getting everything out of your brain into a reliable system where you can retrieve the information on demand.

Two books that helped me very much are the classic "Getting things done" by David Allen and the rather new "Building a second brain" by Tiago Forte. Both books stress the importance of gaining clarity and peace of mind simply by writing things down and saving them in a retrievable system.

The simple act of writing itself will simultaneously help you to dive deeper into a topic and to identify the little details and the holes in your current concepts. The resulting good documentation will also help you to zoom back into the topic if it should emerge months later or simply pull up the necessary context info for the next meeting. As a side note: Depending on your preference any type of Miro board or mind map could do the job as well for you. As long as it is permanent and you can retrieve the info on demand.

On a higher level, these systems give me also clarity about the big picture. They force me to define the next steps for each big initiative and make procrastination painfully visible.

Go deep on deep work

Whether you need to get into the details of a PRD or develop your pitch for next quarter's product strategy: Block some time for uninterrupted deep work. Uninterrupted for me means turning on a little app called freedom to make sure that absolutely no Slack message can lure me to jump on the latest trend in the tech-issues channel. It's amazing what you can get done in an hour of uninterrupted deep work.

Take care of yourself

I know this sounds surprisingly new-age coming from me, but scientific studies have shown the positive effect of sleep, exercise, and recreational breaks on your mental performance and the severely negative and long-term impact if you lack these.

Use templates and frameworks wherever possible

There is a good reason why the PM community likes templates and cookie-cutter frameworks wherever possible. Even though I am a contrarian and skeptic when it comes to blindly following any framework, especially the small mundane tasks of product management can become much more efficient when using templates. My one on ones are always structured the same way. I have a snippet for product announcements and templates for PRDs, Jira Tickets and Roadmap items. I change them wherever needed but I am much more efficient filling in the gaps than trying to remember my "proven" structure every time again.