Welcome leaders,
Internal projects to drive operational efficiencies vs. customer-facing projects — they’re the same, right?
Not so much.
Anyone who has ever been involved in managing or supporting an internal efficiency project can back me up on this.
Today I’m going to guide you through the 5 phases of efficiency projects and point out the places where things can go sideways for you.
Think of it like a treasure map but with less walking, digging, and pirates ☠️
Cheers,
Setting the Stage
Managing internal products is very different from running most customer-facing products, especially when it comes to delivering on efficiency-driving ⚙️ initiatives.
(Btw, I write about the differences between running internal and external products here).
Most of the time efficiency-driving projects have a goal to deliver improvements for internal teams (such as Operations or Support) in terms of the speed 🏃♀️ at which they do their work. Additionally, efficiency projects are often required to improve the quality 🌟 of the work those teams are doing.
These projects often involve product management & engineering releasing software that improves the day-to-day workflows & activities of the internal teams.
By asking product & engineering to build technology to improve efficiency (i.e. help teams go faster & with better quality) the business can benefit in several ways:
Scale better in order to serve more customers 🧑🤝🧑
Improve gross-margin 📊
Reduce the cost structure of the core service 💰
Improve the NPS scores & their customer happiness 🤝
A lot of tech-enabled services companies (vs. pure SaaS) invest in efficiency-driving projects because as these companies grow their services typically go through phases where they become less efficient and even start to lose money (in terms of their unit economics.)
So these businesses need product & engineering to apply software & technology to the situation in order to achieve the 4 benefits noted above.
But this can be a difficult challenge for CTOs & CPOs who haven’t managed an efficiency-driving project (which tend to be complex) in the past.
What I’ve seen help leaders managing these types of projects is understanding the full lifecycle / phases of typical efficiency projects at most companies. In fact, you’ll be surprised at how much overlap and similarity there is.
I’ve tried to capture 5 primary phases here in hopes that it helps leaders successful navigate these kind of projects:
5 Phases of Efficiency Projects
Phase 1: Navigating the Chaos 🤔
There’s usually a bit of confusion at the start of an efficiency project because it’s simply not as clear-cut as building product for an outside customer with specific needs that they are willing to pay money to solve.
Internal stakeholders from across the business will likely have different views about the efficiency project. Some won’t be sure what the project really means at this early stage. While others will have overly high hopes about what the project will do for the company in terms of lowering cost, scaling better, improving gross margins and so forth.
The team that the project is designed to serve & benefit will sometimes have the LEAST to say at this stage. It might be because they are simply happy with any technology as long as it works and makes them more efficient. And the quietness may also be because these teams aren’t looking to become product designers — they have enough work on their plates.
One thing is for sure: Product Management & Engineering will be caught in the middle as things kickoff. But, that’s not that unusual, right? 😆
Product and engineering will be in discovery and definition mode in this phase. There will be a lot of ideation going on with internal stakeholders which product will have to fight hard to drive forward with stakeholders who often have other priorities.
The funny thing at this stage is that no one is exactly sure if the project will actually drive efficiencies that result in business value. At most, product management & the teams using the products will have some gut instinct about it…but nothing concrete.
Realistically you can’t always know what the efficiency outcomes will be until you actually build and use the product internally. But good companies will still take the time to model and make educated predictions.
In this stage if the product team is good they’ll be doing lots of user interviews and building mockups to test out with end-users. This will help bring a lot of clarity to what the formal requirements should be.
Side note: Engineering really should take a very light-weight approach to prototyping at this stage with a minimal of code being written.
Phase 2: Rapid Product Experimentation 🧪
Once the requirements are in place, Phase 2 of an efficiency project usually involves experimentation in terms of rapidly testing ideas to see what works to efficientize internal users.
Features are going into production & scenarios are being tested in this phase, but real value creation (efficiencies) doesn’t reach its peak yet.
Internal users are playing with the new software ideas and providing a lot of feedback while Product tries to keep up and adjust the feature designs appropriately.
I also call this stage “The Phase of a Hundred MVPs” because usually the product team is rapidly building features in hopes that at least one will trigger a huge efficiency improvement.
But driving major efficiencies in user workflows is not a trivial effort. What feels compelling in a requirements document often falls apart when it meets the real world, partly because user behavior can be so unpredictable.
I’ve also noticed that many companies make one serious misstep 👟 at this stage and here’s what it is:
The product team will try multiple ideas / experiments but may not see promising efficiency results. But the pressure on product to deliver efficiencies will be so great that they will move forward anyway.
They will keep investing time, effort and dollars in the hopes that something will work out in the future. For example, they reason that “at scale” some of the minor efficiency improvements they observed will compound and ultimately lead to huge gains.
While this can sometimes (rarely) turn out to be true, it’s generally not a good idea to continue to invest in the efficiency project unless new capabilities truly show highly promising efficiency results.
It takes a skilled product leader to decide what is “highly promising” and what just seems good on the surface but won’t necessarily pan out in the long run.
Still, if executed well this phase will make all the difference in terms of laying the groundwork of product capabilities to achieving massive future efficiency results.
Phase 3: Strategic Improvements & Realizing Big Efficiencies 🎯
Assuming the right requirements were developed in Phase 1 and product experimentation has led to discovering highly promising efficiencies in Phase 2, the next phase is strategic product improvements to realize the really big efficiencies.
Ideally, by now the product team has developed a good sense of where to look for efficiencies in the users workflows. And thus it has gotten more strategic about which areas to double down on improving and which areas will bear little fruit.
At this stage the product team should have escaped “The Period of the 100 MVPs” phase and must concentrate on strategically exploiting the biggest bang-for-the-buck features by improving them for the end-users.
Meaning, both the product team and the end-users have gained the right experience by collaborating together so they know what will probably work and what won’t.
Also, end-users should start to see significant gains at this point. And the general feedback from these users should be highly positive since in theory, product has been improving both their speed and the quality of their work.
If the big gains in efficiencies aren’t being realized at this stage the product team & other stakeholders may have miscalculated.
Remember, the juice must be worth the squeeze. So if you have to go back and revisit your earlier efficiency experiments to validate their potential, then do that.
It’s better to take a step back and revisit core fundamentals instead of beating your head against a wall hoping that somehow the efficiencies will come through.
Phase 4: Monitor and Adjust to Avoid Backsliding ⏲️
At this stage most of the efficiencies have been delivered to the business.
However, there is a “but.”
BUT, it’s quite surprising to a lot of product leaders running efficiency projects for the first time that if they don’t carefully monitor and adjust the product/features they can actually LOSE the previous efficiency gains.
Yes, efficiencies CAN backslide.
Now, this kind of “reversal of value” usually doesn’t happen with products with paying customers who’ve already given you their money. But it definitely does happen with internal efficiency projects, if you’re not careful.
How does efficiency “backsliding” 🎢 happen?
In many ways, unfortunately:
Some new 3rd party software that’s brought in doesn’t properly integrate with the product
The team structure or workflows / processes change
Your software gathers bugs over time and you don’t fix them fast enough
End-user product adoption doesn’t happen to the level that’s needed
Training stops happening over time so end-users don’t know how to use the software effectively
You can see from this list how easy it is to backslide, thus making ongoing monitoring & adjustments absolutely critical.
This may mean optimizing exiting features, building net new features, continuing to interview and understand user behavior, keeping track of the end-users team / organizational changes, and so forth.
Of course, all this must be done with a likely dwindling engineering capacity. Most of the time since the value (better margins, cost reduction, etc) will have been “delivered” to the business the product & engineering teams will have moved on to other projects.
Yet even if internal stakeholders and users have long since “accepted” the software, constant vigilance and fine-tuning is necessary to maintain the efficiencies.
Gaining efficiencies is one thing but maintaining them is another.
Phase 5: Maintenance Mode 🔧
While there is no real “set it and forget it” concept in efficiency projects (due to the on-going monitoring needed) they do come to an end at some point.
But their ending is typically not because the efficiencies were achieved. Usually, it simply because the business has shifted to other priorities.
The work that was done to build the efficiency-driving features may have been good work. And by now that work may have gotten baked into the daily lives of the end user, which is good.
Regardless, the project enters into a kind of maintenance mode where product & engineering leaders don’t have to be as vigilant about efficiencies backsliding, but still have to make sure the product gets the necessary attention to maintain it for end-users.
Of course, the business might come back for more efficiencies at some point. And in that case leaders must dust off their efficiency playbook again.
Keep in mind however that at this point engineering capacity on the project is likely near zero. So a new effort will be needed to assemble the team if more efficiencies are needed.
By the way, getting to this “Phase 5” in any kind of smooth line at most companies is very rare.
To go from nothing to discovering what needs to be built (Phase 1), to running valuable experiments (Phase 2), to fully realizing the efficiencies (Phase 3), then maintaining them forever (Phase 4) and then going into maintenance mode (Phase 5) — all of this is a very tall order to do sequentially and without going backwards, even at very good companies.
Final Thoughts
The open secret 🤫 is that most companies really just want to skip all the steps and get right to building expensive features in the hopes of quickly realizing efficiency gains.
They salivate at the thought of adding gross margin, significantly reducing cost or massively scaling their teams through software that their product & engineering teams have built.
In their hurry however, they tend to ruin an initiative with a lot of potential.
So, it pays not to imitate these kinds of organizations.
Efficiency projects can be very challenging to navigate, so it is far better to carefully think through these projects and proceed in a step-by-step manner, making sure to keep the 5 phases in mind throughout the journey.
For the skilled product or technology leader it is also vitally important to know when your team or business is stuck in a holding pattern in one phase and therefore needs to revert to an earlier phase. Or perhaps you may need to rethink the overall approach / plan altogether.
Successfully socializing these kinds of roadblock scenarios with internal stakeholders takes a special kind of leader.
The last word of warning on efficiency projects is that sometimes there are literally no efficiencies to be gaining regardless of how great the software is that you build.
You & other exes might think there are efficiencies to be had but certain teams cannot be made more efficient with software for a myriad of reasons including simply not having the right people “on the bus.” 🚌
This doesn’t occur to some companies so they dive headlong in a futile attempt to achieve their efficiency goals.
In any case, hopefully the 5 phases gives you a better view and perspective on the lifecycle of efficiency projects so you can lead, plan and manage accordingly.
If you have any questions feel free to email me at podcast@technocratic.io