Hey fellow product people!

I’ve been reflecting on my journey creating feature specifications, and wow, has it been a learning experience. I thought I’d share some candid thoughts about how my approach has evolved from “by-the-book PM” to something that actually helps our Spice Sage team build the right thing.

My Requirements Evolution

When I first started as a product manager, I was determined to be “thorough.” I created the most beautiful, comprehensive PRDs you’ve ever seen—we’re talking 400+ (you read the correctly 400 pages) page documents with every conceivable scenario spelled out. I used all the right templates, included glossy wireframes, and felt incredibly accomplished when I hit “share.”

Then reality hit. Our engineers would skim my masterpiece, ask a bunch of questions I thought I’d already answered, and ultimately just pick out the user stories to put in Jira. Most of my work gathered digital dust.

So, I swung to the opposite extreme. “Agile says detailed specs are a waste, right?” I convinced myself that simple user stories were enough:

• As a customer, I want to see when my spices were harvested so I know they’re fresh.
• As a home cook, I want to rate recipes so I can find my favorites later.

Simple and elegant right? Nope, completely insufficient. Our developers were frustrated by the lack of context, our designers were creating solutions disconnected from business needs, and I was constantly pulled into meetings to explain what I meant.

Finding the Sweet Spot: The Collaborative Feature Specification

Now at Spice Sage, I’ve found a better way. I’ve learned that a good feature specification isn’t about documentation for documentation’s sake—it’s about creating shared understanding. And that can’t happen in isolation.

What Goes Into Our Feature Specifications

For our Spice Sage freshness tracking feature, here’s what our specification includes:

1. Business Context & Goals
   • Why are we building this feature? (73% of home cooks report owning expired spices)
   • What metrics will measure success? (Reduction in subscription cancellations, increase in reorder rates)
   • How does this connect to our larger strategy of building trust in premium spices?
2. User Problems & Solutions
   • The specific pain points we’re addressing
   • How this feature solves those problems (with specific scenarios for both our personas)
   • Scope boundaries (what we’re intentionally NOT solving)
3. Technical Considerations
   • Data requirements (what information do we need to track harvest dates?)
   • Integration points (how does this connect to our inventory system?)
   • Performance expectations (load times for displaying freshness data)
   • Security and privacy implications
4. Experience Details
   • User flows and interactions
   • Content specifications (exact messaging and microcopy)
   • Edge cases and error states
   • Accessibility requirements
5. Implementation Guidelines
   • Phasing approach (what’s MVP vs. future enhancement)
   • Dependencies on other features
   • Rollout considerations

The Collaborative Approach

The biggest revelation? These specifications work best when they’re created collaboratively, not handed down from product management.

For our freshness tracking feature, I scheduled a series of workshops bringing together:

• Engineering (frontend and backend)
• Design
• QA
• Marketing
• Customer support
• Supply chain experts (critical for understanding how harvest dating actually works!)

Instead of me writing a spec in isolation, we built it together. We had engineers raise concerns about data consistency across global suppliers. Our customer support team highlighted frequent questions they get about spice freshness. Our supply chain folks explained the realities of batch tracking.

Each perspective made the specification better, more grounded in reality, and—crucially—created buy-in from the team who would implement it.

Documentation That Lives and Breathes

Another key difference: our specifications aren’t static documents. We use a collaborative tool like Confleunce where the spec evolves throughout development. When we discover new edge cases or technical constraints, the spec gets updated. When customer feedback suggests a tweak, we incorporate it.

This living document becomes the single source of truth, but it’s owned by the entire team, not just me as the product manager.

Has This Made a Difference?

Absolutely. Since adopting this approach at Spice Sage:

• Development velocity has improved (fewer misunderstandings means less rework)
• Feature quality is higher (we catch edge cases earlier)
• Team morale is better (everyone has input and context)
• I’m spending less time answering one-off questions and more time on strategic work

Most importantly, this approach scales far better than either of my previous methods. As we grow our product and team, having this shared understanding documented (but not over-documented) helps new team members get up to speed quickly.

So Who Should Be Involved?

I’ve found that the right mix of collaborators depends on the feature complexity, but the core team should always include:

• Product (that’s me!)
• Engineering (both frontend and backend perspectives)
• Design
• QA

For features with specific domain requirements, we bring in:

• Marketing (for anything customer-facing)
• Legal/compliance (for anything with data or regulatory implications)
• Operations (for features that impact fulfillment or support)
• Subject matter experts (like our spice sourcing specialists)

The key is to involve people early in the specification process, not just at review time. When people help create the spec, they’re invested in its success.

What I’ve Learned

If I could go back and give my younger PM self advice, it would be:

1. Specifications are about shared understanding, not documentation.
2. The process of creating the spec is as valuable as the spec itself.
3. Different features need different levels of detail—be flexible.
4. Keep specs living and evolving throughout development.
5. Always tie specifications back to user problems and business goals.

I’d love to hear how other product managers approach feature specifications. Have you found a sweet spot between over-documentation and under-specification? Drop a comment below!

Until next time, The Spice Sage Product Team