No More Requirements

Some years ago I had an important feature to develop. I assigned Martin, an engineering with ten years of experience to develop the feature. While the feature seemed relatively straight forward, it took Martin three months to fully deliver it. When the feature finally was ready to ship, the team’s product manager showed off the feature during a demo session. Martin finally saw how a customer would actually use it.

“Wait, that’s what it’s used for? I could have built something that filled that need, but better in a few days… In fact, let spend some time on that over the weekend!”

Monday morning Martin enthusiastically demoed his version of the feature, a different feature than the one designed by the product manager, but indeed filling the same need. It was simple, it was elegant, it was obviously the better way to go.

What had happened here? While various things had gone wrong in this project, the most obvious issue was that something had blocked Martin’s creativity to solve the problem in the most effective way. Something that could have been achieved in days ended up taking months.

What was the source of the problem? Requirements.

However, this is only the first problem with requirements. Here’s the second one:

There's an implicit assumption buried in using requirements as a way of communicating between the business/product and engineering side:

The fulfillment of requirements leads to desired business results.

If they don’t, we’re screwed. Even if the implemented functionality fulfills all requirements perfectly, and even in the hypothetical case that they're delivered on time (hah!), your business impact may be zero, zilch. Yet your engineering teams will claim success. “We did it! All checkboxes checked, on time, on budget. High five, party time!”

We spent so much time on ironing out exact requirements, estimating them, negotiating and then... failure. It happens a lot.

Who's to blame? Engineering will tell you that probably the requirements were wrong. Assumptions were made that simply didn’t pan out. “We did what was asked, don’t look at us!” The business will claim engineering was simply too slow. Chances are, deadlines slipped, because of the two reasons just mentioned — which will be hard to deny.

An origin story

Let’s take a step back, and look at the origins of requirements.

The book A Seat at the Table describes how the role of “IT” has evolved a lot the past decades, but still is nowhere near where it ought to be. Many companies still carry heritage from a time that considered “IT” as non-core to the business — a supporting function, effectively. While the “IT department” may technically be part of the company, it is considered one that may well be outsourced. Therefore, a lot of IT terminology is contractor terminology. It is designed to be very specific and enforceable, like in a contract. As a result, it is also quite disconnected from the business itself.

At the core this disconnect? You guess it, requirements.

Crudely formulated, the relationship between “the business” and “IT” looked (and often still looks) as follows: “We — the business — have figured out how we shall achieve our business goals. Part of this strategy requires changes to functionality in our product, therefore we have formulated these changes as a list of requirements. Please, dear IT, tell us how much time it will take to implement them. We shall then review the estimates, and negotiate where necessary. Once committed, we expect timely delivery of exactly what was asked.”

You may think: that sounds an awful lot like old-style waterfall, but even companies that (claim to) practice agile, work this way at some level.

While requirements can make sense for a provider-supplier type of relationship, they do come at a big cost: the cost of flexibility and creativity caused by the complete loss of context.

The moment anybody is given a requirement, they mentally shut down and fulfilling the requirement becomes the new goal. It doesn’t matter what the bigger objective is — it becomes irrelevant, we have a checklist of acceptance criteria now. Let’s go!

And that's how a customer problem that could have been solved in mere days becomes a three month project. And potentially, once it’s delivered, it still doesn’t actually have any business impact.

Expected outcomes

So, what’s the alternative?

Rather than asking to fulfill requirements, we should ask to fulfill expected outcomes.

A hand in the room shoots up.

“I’m sorry sir,” an engineer asks, “but... isn't it the job of business and product to translate business goals to things for us to implement?”

Yes and no. Yes, it is the expertise of business and product to figure out where to go and what to build. They are aware of the competitive landscape, they are aware of the needs of the customers, and and may have great ideas of how to fulfill those needs. However: No, that doesn't mean we should build a wall with a tiny little window through which JIRA tickets are passed with ironclad requirements and acceptance criteria, we type the code, mark the ticket as done and score another few story points. Yes!

To earn that seat at the table, we have to break down this wall and own the expected outcomes. Progress made towards expected outcomes ought to be the only thing that makes us feel “productive.” For that to be possible, though, we have to understand what we're building, why, understand how, and be convinced the changes we make will indeed have the expected outcome.

And if not, flag it, and suggest alternatives.

Another hand goes up: “That sounds hard! I prefer just to focus on delivering my tickets on time. I just read this blog post about back-handed estimation poker we can try to improve our estimates!”

That's great, but perhaps a product company isn’t the best environment for this way of working. Perhaps it would be better to look for some contractor position where you're paid per hour.

How do we get there? How do we shift from requirements to expected outcomes?

Shared goals

It starts with shared goals. If success of product teams and business aren’t aligned, it’s an uphill battle, it has to start there. If the company has revenue and growth goals, let product teams take those as their goals as well.

Another hand in my make-belief audience shoots up.

“I’m sorry to interrupt again sir,” — it’s that same engineer again — “but, we have little control over revenue that is generated. We don’t set the prices, we don’t do sales. Should we really be judged on how well those business guys are doing their job?”

A fair challenge, and I’d say: welcome to business reality. Let us mentally switch sides for a moment. Imagine you’re on the “business” side where you’re the one with revenue and growth goals, whereas product teams have whatever goals they feel are appropriate. You know you cannot hit your goals without support from product teams. You’ll say: “But, we have little control over the functionality product teams give us to work with. Should we really be judged on work that largely depends on product teams doing their job?”

The reality of a business is we’re in this together, and we cannot fully control success or failure.

How do we do get there, then? Let’s make this a bit more practical.

One way to implement shared goals are OKRs. OKRs stands for “Objectives and Key Results.” When implemented well, business and product teams share a set of objectives among each other, and figure out how to measure progress towards achieving those objectives.

For example:

Objective: Become the dominant marketplace for buying and selling art.
Key result: raise the number of pieces of art sold from 1k to 10k per month.

The objective describes the larger goal. The key result (often more than one) attaches a number to what success looks like. If it doesn’t have a number in it, it’s not a key result. Note the absence of any feature list or requirements. All we have is expected outcomes.

What needs to happen now is that different parts of the organization, given our shared goals, think: what can we contribute to attain this objective?

Marketing may plan advertising campaigns to drive traffic. Product teams may come up with features that may convert that traffic into more sales. These ideas are what we call initiatives.

What's super important to realize is that all initiatives are a bet, a guess: if we buy a TV ad, 1 million new people will visit our website. If we build Apple Pay integration, 10% more people will end up buying a piece of art. Some may work out, some may not. To reduce risk, on the product side me may run some tests first (see the next chapter). We may ask actual customers if they'd buy more if they’d be able to pay with Apple Pay. We may even put a fake “Pay with Apple” button on our actual website to see if people will click it. If everything checks out, we develop a simple version of the feature to see if indeed the number of sales goes up. If not, we pivot to another initiative. Perhaps payment options aren't the blocker after all.

Usually, there is no lack of solid ideas about what to do. The tricky part is to decide which ones to go after first; to prioritize them.

The role of engineering

This is where engineers earn their seat at the table. When plans are discussed on where to go next, how to achieve our shared goals, I see at least four clear ways engineers can contribute:

1. Effort estimation: The expertise and knowledge of existing systems and state of technology in general should help assess how much effort is required to implement initiatives. At least roughly speaking, and at least relative to other initiatives. This can affect the order of implementation.
2. Suggesting similar, but cheaper alternatives: Understanding the context and expected outcomes, knowing the state of existing systems and technology, we can often come up with variants of initiatives that are a lot easier to implement, but may have similar results.
3. Out of the box thinking: Tech people have a different background, they think differently — I’ve seen many cases where fresh initiatives come from the tech side of things, simply because they have a different perspective. #diversity
4. Planning: Understanding the larger (long-term) goals, we can think about how to develop the required functionality in the most effective way possible. What parts can be reused, what are the dependencies? What increments can we build to bring value faster?

So here’s my ask: before moving that JIRA ticket from “To Do” to “In Progress” understand where it fits in. What initiative is this part of? What key result are we trying to move with that initiative, and do you buy it? This is your precious time we’re talking about — is this the best use of it, or could you spend it on something that has more impact?

Ultimately, this is not about fulfilling requirements, it’s about achieving shared goals.