When teams lie to themselves, they fall apart
When teams take on a stakeholder request to “build my idea” they stop solving problems together and become a workgroup of individuals producing outputs.
There’s a “design thinking” trick.
In design thinking, you identify a user, find top problems, and then develop solutions. But what if you have a cool solution idea already? Just define the user as “people who have this problem,” and the problem as “users can’t get my solution.”
Teams end up having to do this when they are given a feature idea by their stakeholders without any justification beyond “it’s my idea, so you should build it.” Teams still need to “fill out” the other stuff that they are told should be a part of their process (often by the same executives) and end up having to guess what the expected impact of the work will be.
But the impact is made up. The problems they are solving, and the users they are solving for, don’t exist. The team is, effectively, lying to itself.
And when product teams lie to themselves, they fall apart.
Inventing problems
At a high level, a product team has three jobs they need to do before they can start to build: 1) define the problems the team is solving, 2) prioritize the problems, and 3) scope appropriately-scaled solutions to each of those problems. The team’s goal comes from the first of these three jobs: solving valuable problems.
And a shared goal is what makes a team.
Fake user stories don’t provide a unifying goal, because they are not solving a real problem. The team is now working towards solving an invented problem with no “so what” factor beyond “the work got done.” The team has no concept of what success looks like that they can use to make decisions and measure progress.
But by taking on the work, the team gives implicit agreement to their executive stakeholder that the work has value and will yield outcomes that justify the time spent working on it. So a goal has to be invented, along with outcomes and metrics to report to management according to the governing process.
Accountability for those outcomes is passed around like a hot potato. Trust begins to break down as team members try to assign blame for why their work is not impactful. In an effort to isolate the fault, the team reorganizes around the only metric that it can influence: outputs of individual roles.
And because there is no real customer problem and no guiding principle to make decisions outside of authority, each role invents problems it alone owns, for itself to solve. Developers focus on technical problems, premature optimization, and resume-driven programming. Designers withdraw from defining the user experience into visual craft and design systems. Product managers pivot to project management and ensuring strict compliance to Scrum practices.
Rather than a team working towards a shared goal, these are now individuals satisfying contractual obligations. A working group.
Honesty is the best policy
The issue with this failed team was not that they weren’t solving a user-facing problem; it’s not inherently bad to work on something that can’t easily be traced to user outcomes. Being honest with themselves doesn’t mean that the team can’t say “we want to build Widget.”
But everyone — including management — needs to align on what the desired team outcome is, so they can identify an appropriate definition of good for their outputs and prioritize accordingly. Even defining the problem as “we want to build Widget” is fine, as long as this is clear to everyone and it is prioritized accordingly (probably not very high on the list).
Due to the low prioritization, Widget receives an appropriately low budget, which naturally creates scaled-down success criteria, from “we build Widget” to perhaps “we proved building Widget was possible” or “we proved Widget is desirable to users.”
Teams are stable, workgroups are not
A team that is working towards customer outcomes is not tied to delivering features. It is capable of setting experiments, making bets, and managing risks. This team can say “we learned that solution X will not work to achieve goal Y” and can try something else.
A team that lies to itself cannot admit this, because success for them is defined as “build solution X.” Without solution X, the team has no mandate and no reason to exist.
The members of the team that lies to itself are not stupid, however. Individually, eventually, they realize that “build solution X” is not a valuable problem to solve. But without public recognition of this fact, they feel lost & bitter: why can’t anyone else see what I see?
This is the point at which the team starts to fall apart. Enthusiasm evaporates, work that used to energize the team becomes draining. The fate of the working group becomes a race between people leaving and management dissolving it after realizing it’s not doing valuable work.
