From Chaos to Clarity: How We Built a Lightweight Product Framework at Ajax

Making the leap from services to software isn’t just a business model pivot—it’s a full-blown cultural reset. At Ajax Analytics, we found ourselves staring at a blank canvas after years of successful environmental data consulting. As we shifted toward building a scalable SaaS platform, we needed more than just a backlog of ideas—we needed a system.

But not just any system. We’re a small, mission-driven team with limited resources, juggling a market pivot, evolving customer needs, and the chaos of early-stage product development. So we built a product management model that’s lightweight, real-world tested, and deeply tied to our company’s strategic priorities.

🚀 What We Built: The Ajax Product Management Execution Model

Our approach isn’t theoretical—it’s a living process designed to bring structure to ambiguity. Here’s how it works:

🎯 1. Start with Strategy (EOS + Quarterly Rocks)

We run the company on the Entrepreneurial Operating System (EOS), which means every quarter we define 3–5 top priorities—what EOS calls “Rocks.”Our product bets aren’t plucked from a wishlist; they’re directly tied to these Rocks. If it doesn’t move a Rock, we don’t build it.

🔍 2. Define the Problem (MRD)

We built a Market Requirements Document (MRD) to ground ourselves in the reality of our users’ pain.

• Researchers drowning in unstructured sensor data

• Government agencies struggling to trust environmental metrics

• Consultants spending 40% of project time on spreadsheet cleanup

We keep this document short, painful, and to the point.

💡 3. Define the Value (BRD)

What’s the outcome if we solve those problems? Our Business Requirements Document (BRD) outlines the measurable benefits—for the customer and for Ajax.Think:

• 50% reduction in manual data prep

• Visualization in under 10 minutes

• Trustable audit trails for compliance

It’s not fluff—it’s our scorecard.

🧱 4. Build Capabilities, Not Just Features

Rather than a sprawling backlog, we defined core platform capabilities and mapped features to them.

• Data harmonization

• Role-based access control

• Sensor metadata management

• Visualization & reporting

This helps us keep the big picture clear even as we chip away at small tasks.

🔁 5. Deliver in Cycles (Shape Up + Agile Light)

We borrowed heavily from Basecamp’s Shape Up method:

• Work in 6-week cycles

• Only focus on what’s inside the current cycle

• Bet on ideas, don’t backlog them forever

It keeps us moving and avoids the overhead of traditional sprints.

🔄 6. Measure, Learn, Repeat (Lean Startup Loop)

After each release, we check:

• Did we reduce friction?

• Did the customer get what they needed faster or better?

• What surprised us?

We treat every release like a learning opportunity, not a final answer.

🔁 A Closed-Loop System

Our model isn’t a straight line—it’s a cycle:

EOS Rocks → MRD → BRD → Capabilities → Delivery → Feedback → New Rocks

This helps us stay agile and aligned, which for a team of our size, is the only way forward.

💬 Final Thought: You Don’t Need Heavy Process to Be Disciplined

If you're a startup pivoting from services to software: don’t wait until you’ve hired a product manager or built out a dev team to build discipline. Start with what you have. Align your bets to strategy. Stay obsessed with customer outcomes. And be ruthless about learning.

This model works for us. Maybe it’ll work for you, too.

Want a copy of our slides or our MRD/BRD templates? Drop us a line.