Whether you’re at a big publicly traded company or a privately held startup, the software industry is experiencing an unprecedented era of caution from investors. The past 10+ years have been full of go-go optimism, fast growth, and big potential in the tech industry, with lots of billion-dollar “unicorn” valuations for startups. But many once-promising startups didn’t turn out to be lasting, successful businesses. Investors are starting to scrutinize software companies more closely.
All software companies focus on different key performance indicators (KPIs) to measure their success and progress. But at the end of the day, the #1 KPI that the entire organization should pay attention to is profitability. Investors are no longer as eager to support companies that are promising fast revenue growth with low (or negative) profitability. Software companies of all sizes need to make sure they have a product strategy that suits the market’s demand and delivers value to customers.
Even with the recent slowdown of investment dollars flowing into the software industry, there are still abundant opportunities for software companies. Today’s winning software companies can’t go by yesterday’s playbook. Software companies need to have a strong business model. They need to think of themselves as software product companies and use timeless product engineering concepts to continuously deliver value to the market.
It’s more important than ever to make sure your software company has a strong alignment between the business strategy and the technology at hand.
Your business strategy needs to leave the confines of the boardroom and be shared with your engineering team as well as the other teams in the organization.
Let’s look at a few key questions to ask, and KPIs to measure, to make sure your software company is well-aligned for successful software product development – and long-term profitability.
Business-Technology Alignment: Three Discovery Questions Every Profitable Software Company Can Answer
I often meet with software company CEOs and software investors who are considering a new acquisition. It’s surprising how often software companies are operating without a clear product strategy or a disciplined business plan for how to create, distribute, and capture value. They just go forth and start writing code without a clear understanding of what’s going to sell or how profitable it will be.
Too many software companies focus on the technology first, and the business last. But it should be the opposite. Your software company is here to make money, and that means keeping your development aligned with business objectives. Technology should serve the business strategy, not the other way around.
Software CEOs and their technology teams need to ask themselves three questions:
-
How are you going to create value?
Ideally, your company should have a clear idea of what makes your software product unique and valuable in the market. Ask yourself:
- What is the customer need that your software serves?
- How can you stand out from the competition?
- What is your unique value proposition?
Failure to clarify and verify these measurements of value results in wasted energy and time spent building software products that do not solve your customers’ pain points, or make their lives easier with high-value features.
-
How are you going to deliver value?
This is the part where software companies have to determine how they’re going to deliver their software product to the market. This is where DevOps comes into the picture. You have to consider issues like:
- Whether using Amazon Web Services (AWS) or Azure is more cost-efficient when operating your offering
- Whether your customers need a web app or mobile app
- Whether you need to offer your app on the iOS App Store, Google Play, or both.
How you deliver value depends a lot on the market where you’re trying to sell software and the cost of doing so.
For example, if you want to sell software that works with iOS and Android devices, in the U.S. market, iPhone has about a 58% market share. But in global markets, Android has about 70% market share. In some countries like Colombia, home of our talented team of software engineers, the iPhone market share is only 9.6%. So, depending on your market and target customers, you might need to realign your strategy for how and where you deliver your value – and this can affect your software development process, too.
-
How are you going to capture value?
Simply put: how are you going to get paid? When someone is ready to buy your software license or sign up for a subscription, how do you take their credit card information or request payment to book the sale? How many customers are needed for each plan or tier of software subscription? What’s the average subscription value that you’re aiming to get?
This part of the conversation – surprisingly – often gets treated as an afterthought by software companies. Lots of companies build a software product, and only at the end start to ask, “How are we going to charge for it?” Or they’ll forget to build functionality for taking credit card payments or selecting the most cost-effective payment gateway. Or the software R&D team will reach the end of the production stage, and they know that the product has a subscription-based license, but the business hasn’t figured out how much to charge for it, or what packages to offer, or what features are included in a package.
All of this indecision and uncertainty about capturing value can cause serious software engineering headaches. The technology team has to reopen the platform after they thought they were “done.” The product isn’t ready to ship on time, and you’re facing increases in your operational costs.
Business-Technology Alignment: Measure Your Software Company’s Performance and Potential
Everything your technology team is working on should be mapped to a business objective. You should be able to associate your company’s investment in software development (the money you’re paying for the salaries of your software team) to a specific dollar amount of revenue (the value created and the ROI for the business).
Here are a few KPIs to measure your software R&D team’s performance – and how they affect business-technology alignment:
-
Effectiveness:
Most software teams spend 80% of their time on maintenance and fixing bugs, and only 20% of their time on value creation and innovation. These teams struggle to produce valuable software on time and on budget because they are constantly in fire-fighting mode. An R&D team should spend most of its time on the following tasks:
-
- Generating new revenue: Creating value-adding new software products, features, or upgrades that will drive new sales and ROI.
- Protecting existing revenue: Building software products or features that will improve customer retention. (For example: if you don’t build a certain new feature, you might lose a big client.)
- Reducing costs: Building software that helps the business improve efficiency, save time, raise productivity, or otherwise reduce costs. For example, if a new software feature can save the customer support team 50 calls a day at 12 minutes per call, how much money can you save on those labor costs? How could you redeploy that talent to go upsell clients or provide paid support to drive more revenue?
You can calculate your software engineering team’s effectiveness by asking what percentage of their time is spent on new value-creation tasks versus maintenance and bug-fixing tasks. Highly effective teams typically work 80% of their time or more on new value that generates revenue or reduces operational costs.
-
Efficiency:
During a typical week, what percentage of time does your software R&D team spend working on planned activities? Ideally, 70% of your software team’s time should be planned.
These are the main issues that might be slowing down your team:
- Firefighting: Your team might be constantly interrupted by unexpected server-down events, or critical bugs that can’t wait to be fixed and interrupt the day-to-day to attend to these urgent and critical situations. It is important to focus on your architecture and code quality to avoid these events.
- Unclear strategy and product requirements: It is hard to plot a course when the destination is unclear. Even though your strategy is clear to you, it may not have been communicated clearly to the engineering team. When the target is not well defined, the team will constantly have to deal with changes that require much re-work and time waste.
- Heavy support loads or constant interruptions: Context switching is costly. Software Engineering requires full concentration and every time an engineer is interrupted to answer a customer question or to provide a quick status update this concentration is broken and it takes additional time to get back “in the groove.” Minimize interruptions by establishing a dedicated support team or plan for the expected support load.
-
Productivity:
In software development, SCRUM teams use a points system to measure team productivity with a term called “velocity.” Every task gets assigned a point value; you add points to your week’s tally as you complete tasks.
This point system is often misunderstood as “currency.” However, it is more akin to a doctor’s pain scale ( 0= No pain, 10 = Unbearable pain) in that it’s a subjective measure that reflects the engineer’s perceived risk of a given task.
There are a couple of inherent problems with the point system:
1: Points are relative: The point value given to the same task may vary widely. Even though the estimation exercise requires a consensus between the estimators, the reality when it comes to developing the code is different, and it depends on the skill and experience of the developer. Therefore, the actual point-to-time or point-to-development cost conversions are not good formulas for converting points to time or financial value.
2: The Team Velocity is not guaranteed: The team velocity is the average number of points associated with completed tasks in a given timeframe (typically two weeks). Therefore, in terms of probability, the team velocity indicates a 50% chance that the team will achieve the average number of points per iteration. However, there is also a 50% chance that the team will underperform.
A better calculation of the team velocity would be adjusting this formula to use the number of points with a 75% chance of being achieved to avoid setbacks that result in cost overruns.
Our Tech 360 Assessment – a deep-dive analysis of current software R&D efforts – helps you create an action plan for improving your R&D efforts and refocusing your technology team on value creation instead of maintenance.
Business-Technology Alignment: Mitigate Risk, Increase ROI
Business people sometimes are mystified by the magic of software; they don’t want to get into the details, they don’t understand the technology, and they too often let software people get a little too undisciplined. Every dollar you spend on software R&D needs to align with business goals and drive additional dollars of revenue.
Otherwise, what are you doing? Just fixing bugs, fighting fires, and burning through cash.
By measuring KPIs and improving business-technology alignment, your software company is ultimately going to de-risk your investment in software R&D.
Start the process to de-risk your software development effort with an analysis of where you are today. Then accelerate your software development velocity in alignment with your business goals.
No matter what happens with the latest trends in investor sentiment around the software industry, business-technology alignment, creative discipline, and the timeless principles of software product engineering will serve your company well.
Align Your Business for ROI with our Tech 360 Assessment
Business-technology alignment can be tricky to measure. Modularis can help: we’ll analyze your software team’s performance, and recommend a detailed action plan to transform your software company into a revenue-generating engine. You can turn software R&D from another cost center into a key driver of ROI.