According to Forrester’s recent "The US Customer Experience Index Rankings, 2024," “Average customer experience (CX) quality in the US declined for an unprecedented third year in a row and now sits at an all-time low. An unprecedented 39% of brands and 10 industry averages declined. What’s more, performance dropped in all three dimensions of CX quality — effectiveness, ease, and emotion.”
What Rangle has seen is that a focus on cost over quality has destroyed companies' abilities to ship software. We saw large teams at a major CPG get almost nothing meaningful done over 20 weeks, and nobody was held accountable due to the norms of a cost-centric operating model and an organization that had too many project managers and not enough get-shit-done engineers. This will potentially cost that organization hundreds of millions of dollars due to a substandard digital experience. Remember that CPG customers only have a direct relationship with their customers indirectly via their web and social media channels, and the substandard solution will fall further short of the mark as the age of AI moves us from Google’s tradition search relevance to deeply semantic relevance based on large language models.
The lesson: if you can’t ship, prioritize that until you can reliably ship. Anything else is avoidant behavior if you truly want to become digital-first.
Rangle has always had a ship-first, ask-questions-later mentality. While that might sound like anarchy, something magical happens when you ship frequently: feedback, learning, and accountability for having the talent and distribution of capabilities needed to actually do the job. It’s amazing what wild incompetence can hide inside project plans and program dashboards. Working software shipped regularly creates truth.
In 11 years, Rangle has had a 99% success rate. You can define success in many ways, but a simple one is income: for the SOWs we’ve signed, we’ve collected over 99% of the revenue contracted. One reason is our obsession with value and continuous delivery, and our rapid learning in service of it. The second is our focus and talent: we are a JavaScript-first modern cloud consultancy with a 1:3 ratio of architects to developers. Continuous delivery = continuous problem solving. It’s also easy to get agreement (usually) to ship the next most valuable thing. The challenge comes when teams insist the next most valuable thing is optics, stakeholder management, or mechanisms to avoid accountability for business outcomes (usually due to low trust of the organization and other departments).
So when we see a company reinventing a category and shipping continuously with a public roadmap, we get excited. And here are two such roadmaps:
The OKR tool we use: Mooncamp
My favourite note-taking tool: Heptabase and Heptabase Changelog
I love Mooncamp’s “what’s new” section because it shows they are: (a) shipping the next most valuable thing, (b) leveraging feedback to do it, and (c) “signing their work”—they are committed, crushing it, and doing so in public. It’s why we picked them.
Heptabase’s roadmap is similar and goes one step further—they list what’s next.
What I love about both is they show momentum. If 80% of the value comes from 20% of the features, and you always focus on the next most important thing, you can ship value continuously. If you ship small and ship value continuously, you can predict.
If you predict specifics wrong but ship better features with equivalent value, everybody wins, and the benefits accrue.
When you design and build UX on top of working software:
a) you can see the tradeoffs in practical usage,
b) beta testers can give feedback on unintended consequences,
c) the intense focus allows for features that are discoverable/optional and don’t confuse the established base,
d) your product team is fully empowered to solve for shipping immediate value that scales into the future.
This is how you ship software that wins.
This is why enterprises struggle to innovate. This is why the “Innovator’s Dilemma” exists. The status quo is wired into organizations like a wildly hallucinating GenAI LLM due to having inaccurate model weights.
Ship first, ask questions later.
- Shipped the wrong thing? Fix that by taking what you learned. One week cycle time = you learned and improved, which accrues to all future shipments.
- Shipped the right thing but your users are confused? Feature flag and validate with progressive customers. Salesforce does this well. Also, how much can you confuse customers with one week of work? Will they even see it?
- Shipped a terrible architecture? That’s an inexperienced team. Fix that as fast as possible. I’m not joking. Waterfall is as much the result of low trust as a belief in requirements. Ship first, ask questions later. If you do that and it fails, you have an inexperienced, weak, or low ambition team. Fix that.
- Other teams are complaining. If you shipped the right thing, users aren’t confused, and the architecture is evolvable, this isn’t the source of your problems. Rather, you have dysfunctional enterprise bullshit destroying business value. Fix that and don’t mess with continuous delivery. The bullshit I’ve seen teams peddling to the organization due to “optics” and “that’s how things work here” is absurd. They couldn’t ship, or were afraid to ship, and found every excuse not to ship. Four weeks into a critical six-week platform deliverable, “we pivoted to planning and documentation.” What? “Your team is creating a lack of psychological safety by prioritizing working software over following the process.” Everybody obsessed with delivery optics insisted that’s how things work at this company. Global marketing for a multi-billion dollar company and a project with remarkable traction was completely derailed due to nobody wanting to be accountable or collaborative. They kept talking about “the process” and we kept talking about business value. This has cost this global brand at least $100 million, if not $1 billion, in future value.
- Shipping requires experience and confidence. Traversing “the experience curve” organizationally and individually is the unspoken monster under the bed. Andy Grove talked about “task relevant maturity” in "High Output Management." BCG discusses TMSC’s ascent to global dominance. Ray Dalio talks about partnering into your weaknesses in "Principles." All mean the same thing—invest in traversing the experience curve or outsource or joint-venture.
Heptabase also surfaces real priorities, not internal stakeholder requirements. Publishing a public roadmap is a commitment to operating with intent and ambition.
The Backlog is divided into priority 1 to 4. Each priority has only four or five features (less than 20 total).
The backlog is six areas, 21 features. The entire backlog is 39 features, with only five as priority 1.
Working at the moment are five features across App, Mobile App, Whiteboard, PDF, Mobile App.
The 39 features that are shipped, shipped from 2023/9/14 to 2024/5/30. 4.3 per month, or one per week for nine months. If you consider the surface area of most applications, no one would notice as a casual user. But the power users and new users are ecstatic.
The alternative? Over-design and developers chasing poorly validated designs and schedules while spending countless hours in meetings trying to clarify specifications that have far too many assumptions and far too much cognitive load for designers, developers, and managers.
Two major side benefits of shipping:
(1) Once you ship, you de-risk getting everything right on the first go. The next iteration of design and shipping is built on real data. (2) You surface all the experience and quality gaps in your org and teams while giving a real vision to coach against.
But here is the challenge…
Who owns this in your organization? Tech? Design? Product? Digital? There is a good chance no one does… especially as soon as you have groups optimizing for local effectiveness (at massive system cost to the organization as a whole).
And once you overcome that challenge, how do you allocate the right budget and take your organization through the experience curve to operating effectively in a wildly different operating model that exposes those who don’t ship value. How will incumbents respond?
Three Process Steps to Ship First:
1. Simplify
2. Execute
3. DORA metrics
Three Platform Considerations:
- Modern Design system (in a Monorepo for migration or wildly ambitious platforms goals)
- Next.js (React client and server-side; caching and serverless)
- Next.js is a meta-framework for React, not just server-side rendering.
- Server-side frontend? For everything that doesn’t affect state. Client-teams should be able to write queries and format data. The alternative? Ticket and collaboration hell.
- Next.js is a meta-framework for React, not just server-side rendering.
- Vercel for deployment
- It is just so far ahead of what internal DevOps teams can deliver.
What about the backend? For most companies looking to become more customer-centric, start with the frontend. The backend is already there. Our recommendation: ship customer value and let your backend catch up.
All that said, I was inspired by the Heptabase format and created a roadmap for Rangle’s new GenAI operational risk management framework built to get applications from the POC playground into production.
Its basic premise: if you want to use AI for competitive advantage, you need to learn how to ship innovative AI. That means leaning into the new and building your GenAI operational risk management capabilities.
Because with AI, while cheaper software is operationally an advantage:
The ability to ship software that addresses unmet needs and new capabilities will be transformatively advantageous:
I liked the Heptabase roadmap so much I copied the format for our GenAI Experience GRC platform. If you want to see what we shipped in six weeks, go to Airbender.io and register for the beta.
Or, just have a look at the roadmap (similar to the Heptabase format).
AIRBENDER Roadmap
These are the features that the team is working on right now. Limited work-in-progress, an obsession with the next most valuable thing (for customers, feedback, or risk mitigation).
The "Next Up" listing helps the team understand the context of the work… if they see something further in the list, they can consider pulling it up or deferring some features.
Priority 1 is what is rolling into what’s next. We can juggle priorities 1-4 as much as we want, at any time. The team pulls from priority 1.
As items move from priority 1 to "In Progress," other items move from priority 2 to priority 1. It’s amazing how often priorities 3 and 4 stay in priorities 3 and 4 as better, more important items are surfaced and agreed upon.
The backlog is where we keep things we know we need to do after our immediate priorities. This allows us to keep them in our shared context as we build and ship features and reference them as we debate priorities. Blog moved from backlog to priority 1, but we’ve left the backlog item in place for now as we are looking to ship the first iteration of the blog, not the final version. We realized that GenAI application UI/UX and GRC are new and rapidly evolving concepts, and we’d need to support our users via content. We then realized that the blog would be more effective early on instead of the intended docs site (priority 3).
Very little effort goes into the backlog—it’s mostly a vision document. The reason is that the team will learn and have a deeper/better understanding from actual customers or potential customers.
Shipping is what keeps the team focused, motivated, learning, and purpose-driven.
Here you can see the team’s progress from the first release to this week. Six weeks. Working software ready to be deployed into production and evolve from there.
Other core considerations:
- The team is learning as they ship working software, so the team on day 1 is not the team on day 30.
- At Rangle, “two days or too much” is the innovation motto we use to get out of our heads and into working software.
- When you focus on the next most important thing and ship it, you build robust mental models of the problems you are solving.
- When you implement a long requirements document, you learn almost nothing and spend half your time clarifying what was meant. Ideas can’t be considered because that requires documentation to be changed. Team accountability is lost to the “inadequate requirements.”
This is how you move your team along the experience curve. This is how you remove “Noise” from enterprise decision-making. This is how you move past the status quo and fear that result in being more concerned with managing risk than building the right thing.
This is how you ship software.