Rigor is your friend.
When defining the requirements for a system, its best to avoid detail and focus on rigor instead.
Endless prescriptive details are the bane of good requirements. What to do or not do. Features. Capabilities. Constraints. So many things you can say that its hard to tell what to focus on. Too much detail prevents understanding rather than enabling it.
I had a client once who believe their 250+ “user stories”, diligently and exhaustively captured in Jira, perfectly described the system we were to build. Unfortunately, no one else could see through the muddle to understand what we were supposed to do. Not her boss. Not the engineers. Not her peers in the organization.
Understandably, she was frustrated when others said they don’t understand our priorities or even what the MVP (minimal viable product) actually is supposed to be. She had doubtless put hundreds, perhaps thousands of hours into capturing every detail that should be addressed as we built out the product. Her intention, diligence, and technical skill were all exemplary, and yet, the extensive Jira entries failed to do what she most needed them to do: help her collaborators understand the requirements of the product we were going to build together.
In my experience, this is a common pattern, a perfectly natural result of product managers and engineers focusing on quantity and detail rather than rigor, clarity, and focus.
Working together, we were able to build a consensus with the founder of the company (and our boss) about the #1 focal use case. That use case not only provided clarity about how engineers might choose between tradeoff in early development, it cemented understanding between the technical team and the founder about what capabilities and what work are most important to the near term success of the company.
When we were able to focus on a single use case, we were able to answer–even as a temporary conclusion–questions that were preventing software development from moving ahead. The rigor needed to understand, gain consensus, then implement that single use case proved to be far more practical, actionable, and valuable than the year’s worth of accumulated “user stories” in Jira.
Don’t get me wrong, the background work in fleshing out the full range of requirements was useful. It provided the foundation for distilling that single focus use case and served as an indelible record of the research and experimentation performed in the early days of the company. It was, on its own merits, solid work.
Yet it wasn’t until we stepped back from the cacophony of requirements in that seemingly endless Jira database of “user stories” that we were able to execute on the vision. When we rigorously worked through how just one single use case would work it required a system architecture–even as a strawman for discussion. It also required acknowledging and sandboxing additional capabilities that while important and interesting long term, simply didn’t apply to the one single use case. When we let the focal use case filter the endless possibility of the product into a single interaction, the system requirements solidified into a proposed design and working code in short order.
Yes, the code was incomplete. No, it didn’t do everything the ultimate product would. But it ran. It was demonstratable. It created the ground for the next phase of the conversation between product management and the company’s executive team.
In short, the rigor of understanding a single, limited, focal use case proved to be immeasurably move valuable than the exhaustive detail of hundreds of user stories.
So the next time you’re collaborating on a new system, right the urge to specify every last detail, to exhaustively list all the things it could do, and instead rigorously figure out how the product will do the one most important thing it needs to.
Do that and you’ll create a real product, capable of becoming that amazing vision rather than creating an unattainable vision that no product could encompass.
