There Are No Requirements
Why I Stopped Pretending to Know What’s “Required”
It’s a Friday afternoon in the Spring of 2019, as two engineers and I walk briskly down the stairs to the first floor of our building. With my laptop under my right arm, like a schoolbook, as we make our way to the conference room at the southeast corner of the building — I ask Jane and Tom about weekend plans.
As Soon as We Wrap Up Here
“I’m hoping to get home early today, if I can,” explains Jane. “My kid was starting to get the hang of hitting a tennis ball last summer, and this is the first weather we’ve had this year to get him back out on a court to try to regain some of the momentum.”
“Oh, that’s so fun,” I affirm. I had gone through a tennis phase as a kid and loved it.
Jane is the highest-horsepower programmer I’ve ever worked with. She’s written large portions of our codebase singlehandedly, but always has the time and patience to help me understand technical aspects of our product, whenever I realize I’m naive to something I think is important to understand.
Tom, who had moved from the East Coast when he joined the company, was hosting his parents for the week. “They’re flying back to New York on Monday, so I’m trying to show them as much of the city as we can cover this weekend,” offered Tom. “I’m gonna go pick them up, as soon as we wrap up here.”
No Grace Period
As we reach the door to the conference room, we all see that it’s still occupied for the meeting prior to ours. We can’t see who is in the room, as most of the room’s glass wall against the hallway is frosted. But we can see the feet of the group sitting around the table.
Jane checks her watch and mutters something under her breath. “I’m knocking if they’re not out in the next 25 seconds,” she announces to Tom and me. “I can head out as soon as we’re done with this meeting, so it’s our room at 4 PM on the dot — no grace period!”
Tom and I exchange a look and chuckle at her sarcastic tone, mostly because we’re not sure it’s entirely sarcasm.
It’s Our Room
The door opens from the inside with 10 seconds to spare. We exchange hellos with the group that exits, and we all grab a seat — mine nearest the far end of the table, so I can plug my laptop into the TV hanging on the wall. The sun shining on the parking lot outside — which isn’t a given in the Portland area — won’t be up for much longer. Time is of the essence.
Perhaps not the optimal moment for a philosophical debate. Nevertheless, here we are.
I Just Need Requirements
Our team is responsible for the APIs for checkout in all of our company’s 12 commerce-enabled digital experiences across North America, Western Europe, China, and Japan — and we dive into discussing my sketch of a plan for an upcoming project.
I’m not done reading aloud the first bullet in the “Open Questions” section of the doc, when for the third time in about a month, Tom starts into a rant that by now feels almost as familiar as the “Chinese Restaurant” episode of Seinfeld.
Tom interrupts my question about the technical implications of the planned scope, announcing, “I just need requirements. Tell me exactly what to code, and I’ll code it…” He goes on for about 30 seconds.
When Tom finishes making this familiar plea, I take a beat, to try to estimate how much trust I have with Tom. He’s a very capable engineer, who I know always wants to do the right thing for our users, product, and company. We have a good rapport socially, and he’s complimented me before on my ability to PM our unusually technical product. I’m not sure if Tom will be persuaded by pushback, but he’ll at least hear me out.
Totally Fair Game
If I say what I’m actually thinking, it will be the first time I’ve ever said the quiet part out loud. I’ve been thinking it, silently, for at least a couple years, but I’ve never vocalized it to anyone before.
This prolonged pondering is very much a Dan thing to do. It’s not so much that I have imposter syndrome or low self-esteem. I have no self-esteem. Not negative, nor positive — just a blank whiteboard. I’m now confident in plenty of situations, especially professional ones, but only once I feel it’s been earned. Until that mental whiteboard lists more pros or cons as relevant evidence of my competence or preparation, I’m neither confident nor insecure in a given situation. I can’t put my finger on the precise moment I unconsciously adopted this posture, but I do have a list of suspects under investigation.
I am an only child. There is one of us. When people speak of “strength in numbers”, I have to assume that 1 is not among the “strong” numbers to which they refer.
I was homeschooled through my 7th grade year, during which a cute girl my cousin was friends with seemed to find endless amusement in my mentioning that the next day I would “do school” before going to basketball practice. I’ve since learned this is not a common phrase for American teens.
When I played basketball in elementary and middle school, I wore sports goggles with prescription lenses — think Kareem Abdul-Jabar, only pasty white, 5’ 8”, and coming off the bench. Shocking as it may seem, sports goggles are not a high-status fashion accessory in 7th grade, especially with 7th grade boys who all know each other from class and are introduced to you as the kid who is somehow on the school’s team without actually attending the school.
And while my hair is darker now (and hard to notice with my receding hairline and buzz-cut), I had red hair into adulthood. While most adults are blissfully unaware, red hair actually is the last remaining physical attribute a human can possess that society deems totally fair game for mockery.
At some point, I gathered that I need to earn social capital. I have neither the face, nor the personality, to realistically expect it to fall in my lap. So floating a heretical notion, as pushback to Tom, feels far from a safe move — especially on this rare, temporary sunny Friday afternoon.
What if I’m wrong? I can live with that, and it’s better to be convinced I am than stay wrong longer than I need to. Worse though, what if I’m right, but I fail to articulate my argument well enough to persuade? I may learn something about how to better make the case next time, I suppose. Perhaps worst of all, what if I try to make my case, and Jane and Tom couldn’t care less — just becoming frustrated that I’m dragging out this meeting?
Only way to find out for sure is to ship. So, I take a breath and then let it rip.
There Are No Requirements
“Well, here’s the challenge with the notion of ‘requirements’ though,” I begin to explain to Tom.
“There are no requirements. I could write a bunch of stuff down and tell you it’s all required, but the only real requirement is to build the best thing we can — and no one person on our team is equipped to figure that out on their own.”
Hoping to make clear that I’m not trying to abdicate any of my role’s responsibilities, I add, “Don’t get me wrong though; I’m doing everything I can to make sure the problem is very valuable to solve and clearly articulated, before we start investing the rest of the team’s time. And I do my best to sketch out a draft of a plan — hypothetical scope and potential shape — for how it may all work well.”
I pause, noticing a contemplative look on Tom’s face.
“But if we try to solve it exactly how I think is best, it’s going to be worse than it could be if the rest of the team is involved in making design decisions and trading off scope based on complexity and effort. You all have a ton of important knowledge and skills that I don’t.”
I then pull up a diagram to show on the TV at the front of the room, illustrating our domain’s APIs, the microservices behind them, and our key downstream dependencies.
Shifting my eyeline away from Tom on my left, toward the large TV to my right, I continue, “We’ve got five front-door APIs, and they all need to work well together for all 12 of our front-end teams. And every request to each of those APIs depends on some number of the two dozen microservices in our domain — most of which depend on some mix of at least a half dozen downstream domains, so—”
Before I can finish making my point, another voice interjects.
Where You’re Coming From
“And we support six different product types, which each have different buyability rules and factors impacting when and how they can be fulfilled in various situations,” adds Jane, the most senior engineer on our team. She continues at a swift pace, ”Different product types can be combined into a single cart and delivered to various location types via one or more fulfillment types.”
Whenever Jane speaks on technical topics, she almost always speaks quickly. But it still feels like her mouth’s ability to vocalize words is a giant bottleneck for getting her thoughts out of her head and delivered to the rest of us. It’s lucky for us that her voice can’t go as fast as her brain, or none of us would have a chance of keeping up! Jane is deeply respected as an expert across our entire team, including myself, so her support carries a lot of weight in any team discussion.
She continues, “And then a lot of our system’s behavior differs based on the country the user is shopping in. Our system is complex enough that I’m sometimes surprised by something I hadn’t thought of until I’m part-way done coding a change. If I can’t think of everything up front, how could Dan, who isn’t in our code base every day, spell out exactly what’s required?”
My eyes slowly widen.
Wait, I’m not alone in making this argument?!
Trying to bring it home, I thank Jane for her perspective and conclude, “So yeah, it’s all way too complex for me to foresee all possible scenarios we need to handle in every service, and spell it all out in detail before we start development. And even if I could, I should not be making every single one of those product decisions in a vacuum, right? Is there any chance I’d make every decision correctly ahead of time — without leaning on the rest of the team now, and even as we discover decisions we need to make during development?”
As I stop talking, I unconsciously hold my breath. Now it’s Tom’s turn to take a beat, as he considers my pushback.
It takes, in my estimation, approximately 18 months of silence for the next five seconds to tick by on the clock in the corner of my laptop screen.
The tension peaks as Tom finally starts to reply, “Ok, yeah, that does make sense, actually. Thanks for explaining where you’re coming from.”
Wow, it worked!
I try hard to not let my delight show on my face, as we continue our discussion. We then proceed to review and pick apart the planned scope and design — this time, with Tom fully engaged in the discussion. We go on identifying gaps in the plan, aspects that may not be technically feasible, parts that may be more effort or cost than they’re worth, and even ideas Tom and Jane have that I haven’t thought of, to improve how the design would support the front-end user experience that our APIs will be enabling
But Not Really
In the coming weeks, I’d eventually realize it had not worked entirely.
I’d convinced Tom of my points intellectually, but on some level, that wasn’t enough. Over the next 2 years that the three of us would continue working together on that team, Tom would rerun the “Plea for Requirements” episode of his sitcom in syndication, at least once per quarter.
But, I understand from getting to know him over the years, that Tom’s posture had been formed based on his frustrating experiences with Product folks in the past, who were either lacking in competence or work ethic, failing to drive appropriate clarity for engineering. So I totally get his desire for clarity. If you get burned badly enough in any context, it’s natural to build fences that defend against repeat offenses.
While I had not fully convinced Tom, something had changed in me. Jane’s support for my argument poured wet concrete into the form I’d laid in my mind. She is whip smart and extremely effective. And we are always able to be extremely effective working together. If she was willing to cosign my assertion that there are no requirements, I wasn’t as far out on a limb as I feared.
It was formative validation and would help me to refine how I’ll work with my teams going forward. I now have more evidence on which to base my confidence. And working with other teams, on other products, in the coming years — the evidence will continue to mount.
Generally speaking, there are no requirements.
No More Stone Tablets
In hindsight, it maybe shouldn’t have been a complete surprise that Jane chimed in to help make my point. After all, working with her over the prior 18 months had helped to solidify my perspective about the mirage of “requirements”. She was always quick to contribute to product thinking, leveraging her deep technical expertise.
Jane would sometimes ask, “Would it work about as well if it worked this way instead of that way? Because if so, it would save about two weeks of development time.” And she would sometimes even give non-technical pushback, things like, “Wouldn’t it be more clear for the user to see that information in the Cart screen, rather than having to wait until they proceed to the Shipping step of checkout?”
She intuitively understood that almost everything is negotiable. That’s why I loved working with Jane!
Working closely with experts from other functions, like Jane, who wanted to join me in the process of figuring out what the best thing to build was, had convinced me over time that it would be hubris to present what I thought we should do as being “required”. Collaborating with key engineering and design partners (and sometimes others too), we’d always arrived at a better plan than I first presented.
And even after we started development, we would sometimes discover decisions to be made — or find reasons the plan should change. Even after up-front collaboration, we hadn’t really found “requirements” but instead a better plan. Since plans can change, we would still opt to pivot, if and when we learned more.
If even Tom could be convinced — at least intellectually — that the notion of “requirements” was closer to a fantasy than an ideal to organize our team’s entire workflow around, I suspected this heretical thought didn’t need to be kept such a secret.
Since then, I’ve become honest and forthcoming with all my teammates on this topic, typically raising it in my first 1:1 with each new colleague:
I’ll try to rarely use the word “requirements”, because almost nothing is truly required. Since you and the rest of the cross-functional team will have really relevant knowledge and skills that I don’t, we’re going to have to collaborate to figure out the best thing we can build. So please always be vocal about any input, feedback, and even pushback you may have about the planned scope and solution design. If you can foresee a pitfall or think of a way to solve the problem with less effort, I hope you’ll speak up so we can factor that into our plan. All I want is to get to the best product we can, and I believe that takes all of us.
Isn’t this just semantics though? No, I think it’s an impactful mindset shift for me and the entire team.
While some teammates I’ve worked with, like Jane, naturally ignore the “requirements” terminology and dig in without prompting — many aren’t as bold. But I’ve found many more teammates, Tom included, are willing to contribute to the product beyond their narrowly prescribed functional lane, when I disavow the usual premise. No one is better off when we share in the delusion that only Product people are qualified to think about what to build — trekking up to the mountaintop and coming back with “requirements” etched on stone tablets.
Yes, sometimes there are actual requirements, and I try to reserve the term for exactly those situations. But for most products, very little is truly required, if anything at all.
The requirement is to build the best product we can, and getting there takes all of us.
The preceding is a reconstructed narrative based on actual events. Names have been changed, and some details have been condensed or rephrased to concisely illustrate the core experience.