Most software product portfolios are pretty complex. A seemingly simple web app can eventually spawn APIs, external integrations, native mobile apps, customer service functionality, operations tooling and more. Teams large and small have difficulty keeping track of the functionality without diving back into the code, the product itself or interviewing others to cobble together context. It is a tangle of unstructured data that can grow exponentially. Attempts to capture portions of it in spreadsheets is a feeble task.

While organizations eventually converge on best practices in a number of problem spaces, their journies can often be meandering or fraught with internal politics and costly debate. Despite leveraging itterative small releases, many Product Managers and Developers we’ve spoken with have conveyed pain around the uncertainty in everything they do. We propose organizations structure data for across a few key dimensions through integrations and automation: Offerings, Deployment Targets and Story Specs whose metadata can be tracked across time. This is something teams my know informally - for instance, the web app supports XLS export, but the iOS app does not. Slight tweaks to structuring the data that already exists so it can flow together can have profound benefits for teams.


What are the core deliverables to the end user?

  • iOS App
  • Windows Desktop Application
  • Web application
  • API’s
  • Customer Service Tooling
  • etc.

Deployment Targets

Where will these offerings originate, be tested, and reside?

Nothing special here - we’re structuring what most organizations already do. If you do not have adequate pre-production environments or automation, please bask in some DevOps automation love. Our standard template we recommend to organizations is:

  • Local (Developer Laptop/ Code Repository)
  • Development
  • QA (Many skip this one)
  • Staging
  • Production

Story Specs

Structured portfolio functionality

This is the bread and butter of quantifying your offerings’ functionality and features. We encourage organizations to align to a domain realevant product corpus such as HipSpec’s B2B focused library.

A Story Spec is a definition of a product concept that teams can leverage to improve alignment. Story Specs comprise of reusable Titles, User Stories and Acceptance Criteria, with addition information like descriptions and meta data like tags. Take for instance the screenshot below of User Avatar Upload. It was crafted and tagged so everyone in your organization can understand context. Moreover - the Story Spec provides your designers and developers best practices guidance to help reduce technical debt and improve delivery.

Story Spec Screenshot

The core content provided in the example is concise, easily understandable and measurable. Imagine augmenting your team by simplifying the data gathering and rote decisions. The DevOps & Site Reliability Engineering (SRE) ecosystem has embraced reducing toil, and improving reliability - we believe some of the concepts can revolutionize the product development side of the house. Maybe ReqOps (Requirement Ops) will become a thing and future conference circuit - but until then we’ll keep dreaming.

Shifting to a metal framework of distinguishing functionality as commoditized, foundational work vs differentiated secret sauce is a huge unlock for product teams.

Story Specs seek to help teams shift more items to the left side (Foundational and Commoditized) so that they can focus on the unique problems for your business (which you can also track). These Story Specs can be leveraged for guiding greenfield or legacy cataloging.

Spectrum Image

All work teams do exist on this spectrum. Generally speaking, you should avoid taking commoditized work and putting secret sauce style effort into it. That’s often called “Over engineering” or “Reinventing the wheel”. Avoid it at all costs unless that’s your explicit value proposition to your customers. (Or you’ve run out of things to do, but that’s another discussion.)

The more work you can shift to the left side of the spectrum, the more bandwidth you have for items on the right.

Metadata - Status and Time

Today, 60% of knowledge workers’ time is spent on work about work. At work, people face an overwhelming volume of communications from email and messaging applications, many of which are asking for status updates.

  • ASANA S-1 Filing with the SEC [Source]

Think about that quote for a moment. For starters - alignment across organizations regarding product functionality and other topics is essential for rallying team members to “row together.” However, we can’t have our highly paid talent focusing on work about work instead of doing real work. Deliverable status is a fairly bounded set of states in the world of software.

For any given piece of software functionality, we can categorize something as:

  • Considering - on our radar, doing research, etc
  • Planned - it’s prioritized & in the project backlog
  • Coding - initial steps have been made in creation
  • Coded - coding is complete (code merged)
  • Deployed to Non-Production Environments - Dev, QA, etc
  • Deployed to Production Environments - self explanatory
  • Long Term Stable in Production - deployed for 15+ days
  • Not applicable/ Not Pursuing - lack of clarity here is painful
  • Snoozed - will revisit down the road
  • Unknown - a catchall until another state is applied

This data can generally be encapsulated by TODO, DOING & DONE states as well as custom states in various tools or the appearance of code in certain places. We recommend teams avoid custom states in their tools. Labeling is great, custom states and flows can wreak havoc on maintaining flow & cooperation in teams. (Deserves a Future Blog Post)

Outside of work, the most common status update you probably check is the delivery timeline of your online orders. What if sharing the status of product deliverables with your internal stakeholders, clients and cross functional team members was as easy as sending them a FedEx/UPS style tracking number? What if that tracking number provided clarity at a glance, but also had deep hooks into your code repositories, customer interviews, research, design and project management tools. What if we layered back in the structured concepts of Offerings, Deployment Targets and Story Specs?

Can you begin to see how data is already flowing around in an unstructured manner throughout your organization? We’d like to help you unlock it.

If you’re still not following us…

Think for a moment - the automotive industry has converged on key functional analogs such as:

  • Engines - provides power
  • Transmissions - re-gears engine’s power for needs
  • Brakes - stops vehicle
  • Headlights - provides visibility at night
  • Taillights - provides visibility to other drivers
  • Sunroofs - lets you enjoy the fresh air
  • Suspension - improves ride & reliability of vehicle
  • Etc

What do you think the analogs would be in B2B SAAS software?

  • Authentication
    • SAML 2.0 SSO
    • Password Reset Flow
    • RBAC
  • Transactional Emails
    • Order Confirmation
    • Password Reset Email
  • Reports
    • Monthly Active User (MAU) Report
    • Gross Marketplace Volume (GMV) Report

We’ve cataloged about 1,000 pieces of B2B software that you can map and align your against.

  • Mason @ HipSpec

The primary work of software projects today is the assembly and reimplementation of known concepts or solved pieces of functionality. However, in practice, building (or buying) these components, the mental model often begins with a blank slate or a sticky note driven exercise that uses little objective, historical knowledge to accelerate teams forward. We’ll help you quantify what you’re building (and legacy product) so that your team has improved visibility to do better things for your customers.

Because many of these concepts are not objective, they are not repeatable or measurable. This has a few implications.

  • Gathering context has a high threshold
    • Onboarding new hire
    • Cross team collaboration (Think Dev & Marketing)
    • Cross organization collaboration (partnerships or acquisitions)
  • False assumptions about analogs between teams
    • Assumption the X functionality existed but didn’t
  • Unclear communications or expectations


If you can automate visibility and access to structured product data for your team, they can make better decisions with less rework and decreased technical debt.