Fix the inputs, not the outputs

A friend of mine is a design leader at a company with a couple of thousand people. We were recently chatting about the amount of time she was spending reviewing her team's work. It wasn't because the work was bad, but because she had no idea if the design met the needs of the project. She was spending hours trying to reverse-engineer the requirements from the final design.

The reviews didn't feel good for the individual designers either. Their manager was coming in at the end of a project and scrutinizing every little decision without the full context of what the requirements were. As it turned out, the designers also didn't have the full context - they knew how it started, but not how the requirements evolved over time. That information lived somewhere between the manager, the designers, and the project lead, with no clear source of truth.

My friend works in a design team, but I've seen this play out in a variety of settings. Engineers without clear product requirements. DevRel teams without clear metrics. Salespeople without a solid ideal customer profile. Anytime someone's required to fill in the blanks themselves, there's a high chance that it will lead to frustration for everyone involved.

Garbage In, Garbage Out

Every output is an echo of its inputs. If the team doesn't know what "good" looks like from the start, they have to make decisions that they're not informed enough to make. Sometimes it works out, but more often than not it results in conflict.

The person reviewing the output feels that something is "off", while the team is blindsided by feedback that could have been provided as a requirement early, before the work was done.

Good requirements aren't about more documentation - they're about building a shared understanding of what you're trying to achieve.

• What problem are we solving?
• What does success look like?
• What constraints do we have?

By aligning on the answer to these questions early, you make it easy to evaluate the work objectively. Did it solve the problem within the constraints expressed? Yes? Excellent work! Let's ship it.

A Stitch in Time

"But we don't have time to do such rigorous alignment work! They need this delivered yesterday!" I hear you, I understand, and respectfully, I disagree.

You're already spending this time, and more, at the end of the project "catching problems" with the implementation. It feels productive to catch the issues, but doing it after the work is complete is both expensive and demoralizing for the team.

Aligning on the inputs takes time, but it takes less time than trying to reconstruct requirements from an output. It takes less time than redoing the work because someone made a decision they didn't have enough context to make. Investing the time up front pays off in the long run. A stitch in time saves nine.

In order to improve for good, you need to solve problems at the systems level. Fix the inputs and the outputs will fix themselves. - James Clear, Atomic Habits

How to Fix the Inputs

Fixing the inputs isn't hard, but it does take some concerted effort. At your next project kickoff, try asking the initial framing questions:

• What problem are we solving?
• What does success look like?
• What constraints do we have?

Take the answers provided and write them down in a location that can be linked to from the work you do. This provides the base for your requirements doc.

Over time, you'll build up a list of additional questions that are specific to your org, for example:

• Is this intended for new users or for experienced users?
• Are they likely to interact on a small screen, or will they always be on a laptop-sized screen?
• There's a lot of data being processed here. Are users expecting a result within a second, a minute or an hour?

Of course, not every requirement can be known in advance. Discovery happens through iteration and exploration. You learn what users really need, what's technically feasible, and what trade-offs actually matter by trying things out.

That's normal. The problem isn't that requirements evolve, it's that the written requirements are rarely updated as the real world requirements change. The initial assumptions are treated as the "requirements" even as reality shifts. This is even worse than having no requirements at all, as the final output is then evaluated against incorrect assumptions.

When requirements change, don't delete the old requirements. Instead, append to the document and make a note of the date. Then add a "current requirements" section to the top that is a synthesis of everything you know from the initial definition and the updated requirements. This is your evaluation criteria once the project is ready for review.

The Real Definition of "Done"

Everyone has a different definition of "done" depending on their context and point of view. When teams say a project is "done", they mean that the solution is ready for review. In reality, the work is only done when everyone is aligned that this is the best possible outcome given the constraints.

Before calling something complete, review everyone's understanding of the problem and the proposed solution. Ask "Do we still agree on what good looks like? Are the inputs still valid?"

When inputs are solid, reviews become easier. Feedback stops becoming a surprise attack and becomes a shared evaluation against a known goal. Teams spend less time justifying their decisions and more time improving the product. "Done" stops meaning "I hope this is what you wanted" and starts meaning "we all understand why this is the best solution given the trade-offs".

So the next time you're tempted to try and reverse engineer what was required from the final output (and inevitably provide misguided feedback), pause and think about what led you to this point.

Don't fix the output.

Fix the input.