This week, I’m trying something new.
I’ve been thinking about outcomes a lot - we’re building an outcomes feature, I’m talking about it at Propel in two weeks (let me know if you need a free ticket), and I’ve been thinking about it out loud with many of you (thank you!). So I wanted to share a bit about what’s been on my mind.
As always, but especially this time, I welcome your feedback: on the content, on the format of this email (should we just stick to weekly updates?), and - always - on how Glossa is going for you.
What We Shipped This Week
Project Context - Every project is different, but one thing is the same: in every project, clients talk about all kinds of irrelevant things. Now, tell Glossa about what makes this project different, and what’s in/out of scope - and we’ll use that to flag requirements for your review so you can cancel them in bulk. Check out this 1-min demo video!
File Reprocessing - Do you keep a running notes doc that you want to add into Glossa more than once? What’s that, you want to have an auditable history of all of the prior versions that you’ve uploaded, too? You’re in luck! Now, when you upload a text (doc, docx, pdf) document multiple times, we check what’s new and create requirements from just the new part - without losing the context from the rest of the doc.
New Demo Video
Check out our new end-to-end Glossa demo video, including the Library, SOW Checker, and - yes - Outcomes. Great for sharing with friends and colleagues! 😉
Onto the new part…
Outcomes & Mechanisms
My least favorite part of being a consultant was time tracking. We had to track our billable hours in 15-minute increments, and I reserved an hour every Friday afternoon to go through my calendar and page back through my notes for the week to manually enter my time into FinancialForce (that's how long ago this was!)
Although this weekly task was a regular source of displeasure, that’s just the way things were. We gave estimates using hours, change orders were in hours, and clients understood our work in hours. Hours was almost an abstract and arbitrary measure - it was just the cost of the thing, to clients.
Now, obviously, the cost of the thing has changed, and continues to change. If you’re doing T&M for build right now, you will, or will soon, be undercut by a vibecoder who can do it in a weekend. You can do anything in a weekend now.
So pricing is the urgency. But pricing doesn't live in a vacuum - or at least it shouldn't. Which brings us to value.
Things that look easy
Ostensibly, when a project finishes, you measure success not just by on time and on budget, but also by the business transformation that’s happened - more revenue, less churn, whatever.
In reality, you worry about adoption and change management. Go-live is just the start of a long road ahead; business outcomes take time to be realized. And, usually, they’re not aligned… or even defined.
Alignment: Outcomes get decided at the exec level, but they're not always shared inside the company. Your on-the-ground project team often has goals orthogonal to the business transformation; sometimes they're at risk of being replaced by the very project they're working on. No one wants to be the bad guy and tell them that - and no one wants to be the slightly-less-bad guy and tell them the real goals of their project are indeed not just to recreate their old systems and processes, slightly improved, in the new solution.
Well - no one wants to be that bad guy… except a great consultant.
If you can keep the exec and project teams aligned on outcomes, you win the trust of everyone (you also make your job much, much easier).
It’s not only top-down; consultants bridge upward when the project team has more awareness of reality than leadership (thanks to Mike B for that phrase); that reality is what determines whether the outcome is achievable at all. An exec may not know that the data is so bad that solving three other problems needs to happen before they can get near their outcome. The project team knows, though. And a great consultant is able to communicate the three other problems as part of the outcome conversation, rather than just scope creep.
Ok, you’ve aligned outcomes… but what are they? The definition of outcomes feels obvious: it’s how the ROI for the project got justified.
Sometimes in the sales process you don't even get there (you talk about "soft improvement metrics" like we want this process to be a bit better). But most of the time, these are big investments, the ROI has to be there, and it has to be written down. You need baseline, goal, and financial impact to write a good outcome, and each comes with challenges:
baseline values are often not measured, unless it’s top-line revenue
goal values are often hand-wavey - “more revenue” or “more efficient processes” (because writing down a specific goal is scary! Once you write it down, you're accountable to it; specific numbers create losers; vague goals preserve political flexibility…)
financial impact is ultimately why the outcome is worthwhile, but it tends to be dropped for outcomes related to efficiency, happiness, etc.
Those are not new challenges, they’re the same thing you run into any time you set any type of goal.
What’s really tricky for services is the mechanism. A real example: The client wanted to reduce headcount by 50% and decided the way to do it was to build a tool that automated the team's work with 80% accuracy on the first pass. The consultant built the tool, it was correct 80% of the time, and he got paid.
Did he deliver the outcome? No - he delivered a mechanism; that’s the distinction.
Diverging strategies
Shops that deliver mechanisms are scalable, high growth, low stickiness (think quick starts, OOTB implementations). You make money through reusability - the faster you go, the more margin you keep. These are the businesses that will use agents to deliver repeatable processes at scale (like Rocketlane’s Nitro platform). This is also what I expect nearly every proserv team at a SaaS company is going to turn into, which is great, because it drives time-to-value, which drives top-of-funnel and win rate.
When I first started thinking about mechanisms-as-a-business, I assumed it was a race to the bottom that would quickly make services into a commodity, but I was wrong. Actually, the market is growing; cheaper pricing opens up many more opportunities from businesses that were otherwise priced out of digital transformation services. There's a long way from here to the bottom, and a lot of margin to be made on the way down.
On the other hand, work that's anchored on outcomes is anchored on the fully human, slow, bespoke work of traditional consulting. It's managed services and advisory, it has minimal repeatability, requires lots of judgment, and it’s sticky. It's hard to scale because it requires deep trust between the client and the consultant; it requires agency for the consultant to make many changes across teams and departments in the business, something you have to agree to without knowing the full scope of what’s needed; and it requires time, patience, and an openness to pricing flexibility.
It can be an opaque path to get from mechanisms to outcomes; navigating this path is the definition of consultative judgment. The value that consultants deliver when they commit to delivering outcomes isn’t just delivering the mechanism that gets you to the outcome, although that’s important - it’s knowing which mechanisms to prioritize, how to sequence them, and how to adjust when you encounter inevitable bumps in the road.
And so…
Conveniently for me, both the outcomes and the mechanisms strategies have the same underlying information problem: the goals of the project are discussed in sales conversations, and then dropped.
Mechanisms shops need to know which outcomes their mechanisms reliably produce, so they can productize and price and sell against them. Outcomes shops need to know which mechanisms are serving which outcomes on a project, so consultants can make their hundreds of micro-decisions every week with business context instead of in a vacuum. Without that visibility, mechanisms shops can't articulate their value, and outcomes shops can't actually deliver against the outcomes they sold.
So what we’re working on:
Glossa captures business outcomes from your sales conversations alongside requirements - so the outcomes that get the deal signed don't disappear at handoff.
Each outcome has a baseline value, a goal value, a status, and full history, so when the goal moves mid-project, you can see what changed and when.
Every requirement is tied to a capability, which is tied to an outcome (live, throughout the project) so when a new requirement comes in, delivery has the language and the visibility to ask: does this serve one of the outcomes we committed to?
For outcomes shops, that's how you keep a project anchored to the business case. For mechanisms shops, that's how you build the outcomes-to-mechanisms-to-requirements map you need to productize repeatable work. It’s the same infrastructure, with different value.
Whichever lane you're in, the work of keeping outcomes connected to requirements is what makes your business viable in this new world. It's also almost impossible to do well manually. Which is why we’re building it!