If your company is in the software business, then you know which applications are strategic: the ones you sell to customers for money. I’ve worked with a series of non-software companies over the last year, though, who are unclear about which of their software applications are strategic – and which provide generic operational support for the business. Here’s how I’ve been breaking it down, and the kinds of questions that should pop up.
A Tale of Three Companies
Imagine three companies: a package shipper, a recruiting firm, and an investment house. Each company charges customers for its services, not for software it might build. I’d classify all three as “technology-enabled,” distinguishing them from pure technology players.
Our package tracking firm (think UPS or FedEx) lives and dies by its real-time logistics data. At every minute, agents and customers must know the exact location of any particular box. New views into the data, or mobile delivery alerts, or value-added billing schemes could be strategic.
The recruiting company (think Korn Ferry or Robert Half) must scan, slice, dice and retrieve thousands of resumés per hour. Matching skills to job requirements is a core capability. Their candidate database is huge, well guarded, and strategic. But tracking packages is uninteresting: they delegate it to their interns.
Finally, our investment firm/ hedge fund (think Farallon Capital or Blackrock) lives and dies by its ability to move money in microseconds. Portfolio algorithms are top secret, trade execution is make-or-break, and reports of stock positions must be perfect. But they remain blissfully ignorant about package tracking and resumé scanning.
You get the idea. Real estate companies might invest in building maintenance software, but not in package tracking or resumé scanning or real-time securities trading. And so on.
Why go to such lengths to make a point? Because I routinely talk with product managers – and product owners and program managers and software development teams – who don’t know whether they are working on a strategic application or an operationally tactical one. Which leads them to poor investment decisions.
On the strategic side…
Your company should have a strategic application. It’s the one with potential to (indirectly) increase revenue or shift the competitive playing field. Executives and customers each have their suggested improvements. And development teams are pushed to create wholly new capabilities that might move the entire business. If you’re working on your company’s strategic application, you should be asking questions like:
- Can our sales team really drive more revenue with this new feature? Will they actually commit to increased quotas to fund this work?
- If we’re late, will the competitors scoop us? Does this new feature become “me too” in 12 months and a visible disadvantage in 24 months?
- Should we be prototyping several alternatives, since each has high technologies risk?
- If we buy COTS (commercial off the shelf software), can we still configure it for competitive advantage? How would we protect our proprietary algorithms or approach from vendors and competitors?
Schwab redefined the entire brokerage industry in the mid 1990’s with its move to low cost online stock trading. Individual investors were able to trade for themselves; traditional brokerage firms were stuck with high prices and comparatively poor service. Their strategic software created top-line market advantage.
Zipcar turned the rental car market on its hood with a combination of business model (hourly rental) and software (mobile apps unlocking vehicles, remote sensors, online reservations). A high-risk investment: custom software purpose-built to disrupt a stagnant market.
But Not Everything is Strategic
Tactical operational software is always about cost reduction.
Unless you work for an accounting firm, your accounting software is just an expense item. Likewise, your HR application will never matter to customers if you’re in the fashion design business. And a payroll system is a payroll system is a payroll system (except at Sage or ADP or Intuit).
So if you’re being asked for improvements to a non-strategic operational system, be very skeptical about top-line revenue justifications. Ask questions like:
- Improvement X is intended to reduce (for example) tech support call center staff growth by 10%. Does our tech support management agree, and will they cut headcount projections once we successfully deploy? If not, then the savings are fictional.
- Is there an off-the-shelf solution that addresses 90%+ of our needs? Why do we need to build this ourselves?
- Which apps do similar firms – including our competitors – use? Since there’s no strategic IP involved, we want the least adventurous, lowest risk choice that other companies have already deployed. There’s no prize for novelty.
- If we truly need to build software ourselves, do we have a track record of on-time/on-budget internal development? We’ll never achieve operational savings by habitually under-estimating the cost and pain of building custom software.
- Our technology staff is limited. If we shelve this project, what else could our developers tackle? Other projects may have higher returns or drive corporate revenue.
Sound Byte
Building software is hard. It needs specific expertise and incurs ongoing costs. Focus your internal development on strategic applications that can truly drive revenue, and be clear-eyed about your company’s ability to enhance/maintain everything else.