Still doing SIT? You're not agile

If your teams are still running a separate System Integration Test (SIT) phase, I’ve got bad news: you’re not agile. You might have squads, scrums, and stand-ups… but if you’re still treating integration as a final boss fight at the end of your release cycle, you’re clinging to waterfall in an agile costume.

The SIT Trap

SIT was born in an era when teams threw code over walls. Developers built in isolation, and only after months of coding did testers try to stitch everything together. Unsurprisingly, it was a mess - like assembling IKEA furniture in the dark after throwing away the instructions.

In Agile, that wall shouldn’t exist. Integration should be continuous. Every code commit, every merge, every deployment should prove the system works end-to-end. If you’re waiting until the end to find out whether your parts fit, you’re running a high-risk casino, not a software delivery team.

Why SIT Won’t Die

Executives cling to SIT because it feels safe. A dedicated phase, a big bang test cycle, a final thumbs-up before launch—it’s comforting. But comfort is costly. SIT:

  • Delays feedback: Bugs found late are expensive and demoralizing.

  • Creates bottlenecks: Test teams become overwhelmed as deadlines loom.

  • Breeds blame: Developers and testers point fingers instead of collaborating.

The Agile Alternative

True agility means shifting left:

  • Continuous Integration (CI): Merge code daily, run automated tests with every build.

  • Continuous Testing: Embed QA into development squads, test as you go.

  • Continuous Delivery (CD): Deploy small, frequent changes, so integration issues surface early.

You don’t wait until the end of a bake to see if the dough has risen or if the yeast worked. No, you knead, proof, and adjust as you go, making sure every stage blends perfectly so the final product comes out golden and ready!

The Mindset Shift

Killing SIT isn’t about skipping testing. Instead, it’s about testing more frequently and smarter. It’s about:

  • Building quality in, not inspecting it at the end.

  • Seeing testers as part of the team, not gatekeepers.

  • Trusting automation to catch issues before humans ever notice them.

If you’re serious about agility, it’s time to retire SIT. Tear down the last wall. Make integration invisible because it’s happening all the time. That’s when you’ll truly be agile… not just wearing the jersey.

Oh, and btw! The same applies to UAT. If you’re still batching work to be “accepted” by someone at the end, you’re also not agile. You’re just running a different flavor of waterfall with sprinkles.

Question: What’s stopping your teams from making SIT obsolete? Is it tooling, mindset, or fear of letting go of the safety blanket?



Free eBook on Creating Customer Value

Learn why choosing problems over ideas will enhance your chance for success in my free white paper 'Creating Customer Value'.

Making The Shift From Feature-Based to Outcome-Led Roadmaps

When Microsoft transitioned Office to the cloud, they threw out their shopping list of features and started chasing outcomes like faster collaboration and stickier adoption. ING Bank also made a similar move - ripping up their feature factories and handing teams a compass instead of a map.

The sad truth? In many organisations, roadmaps are nothing more than wishlists with due dates. Stakeholders fight for their pet features, IT and Tech playing feature Tetris, and teams slogging toward a delivery date everyone knows is fantasy. The result: burned-out teams, wasted investment, and solutions that miss the mark.

Outcome-led roadmaps flip that script. At its core, an outcome-led roadmap is a plan that focuses on the changes and benefits you want to deliver to customers or the business, rather than on specific features. It stops asking “What can we ship?” and starts asking “What’s the impact we’re here to make?”—shifting from counting features to counting real wins.

In my experience working with organisations moving through the transformation from top-down feature factories to outcome-focused and autonomous teams, there are some distinct plays I've seen repeatedly deliver success. Here’s how to start kicking feature factories to the curb:

1. Start with the Mountain, Not the Map

Think of your roadmap as a mountain expedition. Features are like individual supplies or steps along the path. Useful, yes, but meaningless if you’re climbing the wrong peak. Outcomes define the mountain itself: reducing churn by 20%, doubling digital adoption, or increasing average revenue per customer.

In fact, according to Pendo's Feature Adoption Report, only 12% of product features generate 80% of total usage—proof that without clear outcomes, most of what gets built ends up as unused clutter.

When you start with a clear outcome, the route can change. Some gear (features) will get tossed. Others will be improvised. But everyone knows what summit they’re trying to reach.

2. Turn Outputs into Hypotheses

Teams often get stuck phrasing solutions as fixed features. Take a loyalty program as an example: rather than just saying “Build loyalty program feature”, reframe it as a hypothesis tied to an outcome:
“We believe introducing a loyalty program will increase repeat purchases by 15% in 6 months.”

This subtle shift does two powerful things:

  • Makes room for experimentation (maybe the solution isn’t a loyalty program at all)

  • Creates accountability for impact, not just delivery

Companies using hypothesis-driven planning see 33% faster validation of ideas (Lean Product Research Report, 2022).

3. Link Roadmaps to Metrics, Not Milestones

Feature-based roadmaps celebrate delivery dates. Outcome-led ones celebrate movement in metrics.

Swap milestone charts for metric dashboards. Show the trend in churn rate, activation, or NPS alongside planned initiatives. That way, every conversation is about closing the gap, not checking boxes.

4. Shorten the Horizon, Extend the Vision

Traditional roadmaps pretend we can predict 12–18 months of development. In complex systems, that’s fantasy.

Outcome-led roadmaps set a long-term vision (the mountain peak) but only detail near-term bets (the next few camps). This balances strategic clarity with agility, allowing teams to adapt as they learn.

A recent Agility Index study found that organisations using shorter planning cycles (e.g., quarterly) adapt to market changes 40% faster than those locked in annual plans.

5. Empower Teams to Choose the Path

Executives often mistake specifying features as providing direction. In reality, they’re constraining innovation. Set the outcome and the boundaries (budget, timelines, risk tolerance), then let product teams figure out the best way forward.

This shift pays dividends. Empowered teams report 50% higher engagement, and individuals who feel empowered score in the 79th engagement percentile vs 24th when disempowered.

Outcome-led planning only works when decision-making is pushed closer to those doing the work. But empowerment doesn’t mean chaos. Teams must maintain alignment with the organisation’s strategic direction.

Think of it as aligned autonomy: teams have the freedom to choose their path but must still point their compasses toward the same mountain peak defined by leadership.

But What About Infrastructure and Re-platforming Projects?

A classic argument against outcome-led planning in technology teams is: “You need to build the plane before you can fly it.”

While some platforms truly require large foundational builds, the point isn’t to avoid building the plane. It’s to design and deliver it in stages that prove value along the journey:

  • Challenge the either-or decision: You don’t need a finished Airbus to prove lift. Can you start with a glider? Infrastructure can show incremental outcomes like faster provisioning times, reduced downtime, or lower compute costs long before the full build is done.

  • Think modular planes: Just like modern aircraft use modular, tested components. For example, cockpit apparatus and flight controls can be tested in isolation long before the fuselage and wings are assembled. Similarly, platform teams can build minimum viable platforms, validate them with real workloads, then expand.

  • Tie to business outcomes: Even infrastructure exists to serve a business result - speed, reliability, scalability. Express platform work in these terms: “We believe that <solution> will increase CRM stability, and therefore reducing negative Customer Experience reviews by 3%”

  • Run flight tests: Don’t wait 12 months to prove success. Pilot workloads, release partial capabilities to a single business unit, and iterate.

Final Thought: Stop Measuring Progress in Tickets

Shifting to outcome-led roadmaps is more than a formatting change - it’s a cultural and mindset shift. You’re moving from project management to product leadership. From busy work to business impact.

In mountaineering terms: stop counting footsteps and start watching the horizon. Because no one gets remembered for building features on time - they get remembered for the value they created.



Free eBook on Creating Customer Value

Learn why choosing problems over ideas will enhance your chance for success in my free white paper 'Creating Customer Value'.

Product Operations: The Pit Crew Your Product Teams Need

Most roadmaps are wish lists with deadlines. I’ve seen smart, capable teams burn out trying to deliver every line item, only to discover no one wanted half the features. The problem? We’re still running product like projects, with layers of reporting and control, instead of creating an environment where teams can focus on learning and delivering value.

That’s where Product Operations comes in.

From PMO to Pit Crew

In big organisations, executives often lean on the Project Management Office (PMO) to bring structure and predictability. It works… until it doesn’t. PMOs were designed for projects with clear end dates. But modern digital products aren’t projects - they’re living, evolving ecosystems. Applying the same rigid controls just slows everything down.

Think of product ops as a Formula 1 pit crew. The drivers (your product managers and teams) are focused on the race - making bold moves to outpace competitors and deliver for customers. The pit crew (product ops) keeps the car in peak condition: fine-tuning processes, ensuring the right tools are available, and providing data-driven insights to help the driver make faster, smarter decisions.

When done well, product ops doesn’t add bureaucracy. It removes friction.

What Product Ops Actually Does

Atlassian describes product ops as a practice that makes product teams more efficient. I like to think of it as three big levers:

  1. Insights on tap – Great product ops teams surface the right data at the right time. They build dashboards and reporting systems that give teams self-service access to customer behaviour and feedback. No more digging through 20 spreadsheets or waiting three weeks for BI to pull a report.

  2. Smooth processes, fewer bottlenecks – They streamline workflows so teams can experiment, learn, and ship faster. It’s about removing red tape without losing alignment.

  3. Tools and enablement – From roadmapping software to discovery toolkits, product ops sets up the garage and keeps it running so product managers can focus on strategy, not admin.

Marty Cagan (Silicon Valley Product Group) calls this a “force multiplier”. The idea is simple: a small team that makes every product manager more effective. Think coaches, not controllers.

Callout: PMO vs Product Ops

Common Mistake: Rebadging the PMO

I’ve seen organisations introduce “product ops” only to recreate the same old PMO. Suddenly there’s a new layer of reporting, approvals, and planning meetings… and product managers still can’t find time to talk to customers.

Real product ops is not a governance function. It doesn’t tell product teams what to do. It gives them space to focus on solving customer problems. It’s the difference between a race engineer helping you shave milliseconds off your lap time versus someone telling you which corner to brake at.

When to Invest in Product Ops

Not every company needs a dedicated product ops function straight away. Small startups can usually manage without it. But as soon as you have multiple teams or products, patterns emerge:

  • Product managers are bogged down in admin.

  • Experiments take too long to set up or repeat.

  • Data is scattered and hard to trust.

  • Scaling up feels like adding chaos, not speed.

That’s when a pit crew starts to make sense.

Making It Work

If you’re considering introducing product ops, start small.

  • Set clear goals – Decide what problem you’re trying to solve first: reporting, tools, insights, or process headaches.

  • Hire multipliers – Experienced product people who know how to coach and enable, not just manage spreadsheets.

  • Keep it lightweight – Don’t build a parallel product team or a PMO 2.0.

  • Focus on value – Every process or tool introduced should help teams make better decisions or ship value faster.

Product operations isn’t a silver bullet, but for organisations transitioning to true value-based delivery, it can be a game changer. Think of it less as adding structure and more as adding speed. Your pit crew won’t drive the car for you—but with them in your corner, you’ll make fewer pit stops, handle the corners better, and have a real shot at winning the race.



Free eBook on Creating Customer Value

Learn why choosing problems over ideas will enhance your chance for success in my free white paper 'Creating Customer Value'.