Requirements Management might not be a familiar term in the Agile/Scrum Era of software development. As mentioned in our Product Management Landscape overview, organizations have been moving towards a Just In Time delivery system for software requirements. The broader idea is that a team’s assumptions about customer needs are typically wrong and that feedback cycles should be short with direct customer communication. Out with the 6-12 month project gantt charts that are set in stone, in with customer interviews, watching them complete tasks, and direct lines of communication.

At HipSpec, we totally agree with that shift. We love talking to Product Managers, Chief Product Officers, Founders & Developers who use our tool. Many of them are out there to make their own dent on the universe and it’s inspiring to hear them discuss disruption of markets, simplification of process and improvements in their own user’s lives both at work and at home.

Note: Please bear with us on the nuance below - people are putting a ton of heart and effort into their work. We are not trying to diminish that. We’ve seen many earnest attempts to build a swimming pool using a wheelbarrow with hundreds of back and forth trips when a bobcat & dump truck would have been a better use of time and resources.

One of the side effects we’ve observed over the last few years at different organisations is that in the transition to shorter feedback and build cycles in software, organizations and teams are reinventing the wheel on a daily basis. There’s so much amazing reuse happening in the open source ecosystem for “raw code.” But if you take a step back and look at the product discussions within organizations, you’ll see endless meetings between product, development, quality and other stakeholders that revolve around the same corpus of foundational questions.

Examples:

• What should the error message be for submitting the forgotten password form?
• What does an MVP look like for user avatars? V1, V2?
• How do we consider this feature “done”?
• How does Salesforce or [Insert Popular B2B SAAS] do it?
• Our system does not support custom permissions, the user is an admin or they are not. They need to create a second account to access XYZ functionality… how do we migrate to a better solution?
• How will we handle transactional notification email subscription status for the user? Do they have to login?

In most organizations - these questions pop up a week or two before developers start writing code, sometimes, they get discussed in a chaotic furry 3 days after the developer started coding a feature. There is a better way.

Below you’ll see a diagram of how we see the world of software functionality in 4 quadrants.

Along the horizontal axis, you’ll see well defined product concepts and known, but messy/complex concepts. Along the vertical axis, you’ll see common table stakes functionality and Differentiated Value Drivers.

Those two axis comprise a set of quadrants.

Bottom left quadrant: Table Stakes & Well defined product functionality. Bottom right quadrant: Table Stakes & Potentially Messy product functionality. Top left quadrant: Low hanging fruit for your users, might be a slight adaptation of something from another industry, but these tend to migrate down to the bottom left. Top right quadrant: Here are your money makers, your secret sauce, this is what sets you apart from other offerings in the market. Building here is messy, complex, but drives immense value for your users. This is where your team should be focusing, it’s the highest value creator for your business and your customers.

Side note, there’s a well discussed topic in some software circles of “Innovation tokens” - more broadly speaking, these are opportunities to try and hoist something from the bottom left quadrant to the top right. Tread lightly here, it can be a time trap for your team. It can be very costly if your team does not but guardrails on these efforts.

Warning: here comes the marketing/sales pitch…

We think that teams shouldn’t start from a blank Jira, Asana, Clubhouse, Gitlab Issue for the bottom two quadrants. It’s a waste of their time to reinvent the wheel. Even when teans know this, they often spend cycles researching best practices around the internet for a one time implementation. That being said, it’s easy for a team to quickly fall into the trap of thinking they will not get the payoff from a one time implementation. Developers have often referred to this trope about automation - https://xkcd.com/1205/ . What if you zoom out a bit and look at automation of a family of tasks completed in isolation by different teams. While it looks less repetitive on an individual basis compared to someone doing manual data entry on thousands of inventory items in a warehouse. Trends appear quickly.

New organizations don’t often think of these issues, while under-resourced, they will often have high fidelity involvement by leadership, even founders and CEOs in product discussions as partnerships and operations consume less of their absolute time. As organizations grow, so does communication overhead and the potential for internal rework. Eventually, you will see platform teams emerge that attempt to align technical decision making, standardizing key foundational elements such as SSO, Logging, Auditing, or design pattern libraries - https://designsystemsrepo.com/.