No More Requirements

In a previous company, I had an engineer work on a feature for the better part of three months. The feature was well-specified, all requirements were clear. When the work was done, and the feature delivered, a demo session was organized. As the product manager demoed the feature, describing the scenario in which our customer would use it, the engineer said: “Oh, that’s what it’s used for? I could have built something different that filled that need in three days.”

A few weeks ago I wrote about No More Feedback, with a nod to the title of that book, let me share another disruptive idea that I’ll phrase as “no more requirements.” I found this idea buried in another book that I’m reading called A Seat at the Table. The book 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? The concept of requirements.

For the purpose of this article I’ll limit the definition of “IT” to software development work: product teams.

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.

What’s the problem?

There’s a huge-ass assumption buried in this way of working:

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 product teams will claim success. “We did it! All checkboxes checked, on time, on budget. High five, party time!”

We spend so much time on ironing out exact requirements, estimating them, negotiating and then… failure.

Who’s to blame? Product teams 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 the product team was simply too slow. Chances are, deadlines slipped, because of the two reasons just mentioned — which will be hard to deny. So perhaps we have to focus on speeding up. How do we measure product team performance anyway? “Story points!?” That sounds like a made up term, are you serious? Alright, if that’s the best we got, then how do we speed up the number of these “story points” delivered?

While a seemingly attractive path for further exploration, in reality it’s an unproductive rabbit hole. In “A Seat at the Table,” the author argues to take a few steps back: it’s the idea of requirements where problems begin. Requirements can make sense for a provider-supplier type of relationship, but they 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 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.

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 can easily rewrite into Gherkin so that our BDD tests turn red, we type code until they turn green — and then go home feeling productive — another few story points scored. 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 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. Since it’s Friday, let’s pull a Freaky Friday and 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. #dealwithit

How do we do get there, then? Let’s make this a bit more practical. One way to implement shared goals, used by many large companies 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 that objective.

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 is happening now is that different parts of the organization, given our shared goals, think: what can we do 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 we tend to run some tests first. 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 ticket1 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?

  1. Used for rhetorical reasons. Generally the time of moving a ticket on a board is not the most productive time to reflect on things like this. It’d be better to make sure you’re part of the planning process earlier on.