4 Things to Look for to Assess your Software Product Company’s Effectiveness
Let me share you something I realized the other day discussing with a customer: If you are a manager in a product company that has an established product, benchmarking your organization’s product development capability can be hard.
You know from experience that you can ship a product, but how does your capability compare with the competition? What could you (and what should you) improve to stay ahead of them?
Well, here is my take on how to assess your software product development capability: four important things to look for.
They are from the Agile Fluency Model developed by Diana Larsen and James Shore. The strength of the model lies in its adaptability and versatility; it is not a maturity model. It takes into account several different dimensions of capability. These dimensions are not a straight progression of improvement phases. A company can improve in several of them in the same time. There is also a lot of field work behind the model, meaning that with the assessment a company can get a feeling of how effective they are compared to their competition.
Without further ado, here are the four indicators to look for.
1. Reporting Progress in Business Terms
The basic indicator of a working software product development organization is its ability to report progress in business terms.
What does that mean? Simply that the development teams regularly report what they are working on and how it is progressing from a business value perspective.
Why is that important? First, having these regular reports mean that the developers share the business goals that the business has. If not, that will be corrected swiftly during the feedback discussions after the reports. And that is alignment on business objectives which is a pretty potent thing to have in your company.
Second, this means that there is transparency in the development. Things that are being worked on are talked about and the rate of progress is visible for everyone. This elevates trust in the company and makes planning based on reality possible.
What if you do not have this in your company?
Achieving this kind of behavior is what the agile software development methods and frameworks excel in. If you do Scrum, XP or Kanban or a variation of those, you pretty much get this. Provided you understand why you are using one of those frameworks.
2. Shipping at the Market Cadence
i.e. can you ship versions of your product at the maximum rate the market and customers accept it.
What does that mean? It means that you are able to ship product version when you want to (for business reasons), not when the stars align in the technological end of your business.
Why is that important? The most important reason is that you want to be able to seize every business opportunity. If you cannot ship when you want to, you are bound to miss on some.
Another reason is that this raises transparency: if you ship regularly, you get feedback on systematic flaws earlier. Your ability to learn to develop software in a way that avoids these flaws is accelerated.
Frequent releases also result in higher morale and build trust between your company and your customers.
What if you do not have this in your company?
If you are not there when it comes to shipping at will, you probably have technical debt and suboptimal architecture and design in your code base. High number of defects is another factor that makes shipping more difficult. That is usually a result of non-clean code and lacking the support of feedback mechanisms like automated tests.
This is the most skill-intensive of the fluency dimensions. There are a number of techniques to learn. Some are quicker to learn than others. Most teams need training, coaching and consulting to adopt techniques such as clean code, test-driven development, continuous integration and continuous delivery.
3. Providing Concrete Business Metrics
i.e. does your company use concrete business metrics to track how you are doing?
What does that mean? In addition to reporting progress in business terms, do you measure and report your impact with business metrics like sales funnel metrics (with cohort analysis), customer retention rate, cost of customer acquisition, revenue-per-customer etc.
Why is that important? If they report on these things, the product development team is able to optimize the value they produce. They learn how their work impacts the business. With that knowledge they can perfect their efforts to bring maximum amount of value to the company.
Decision-making becomes straight-forward because there are concrete numbers to base decisions on. This builds trust and collaboration in the company.
What if you do not have this in your company?
Executing this kind of reporting requires that the development teams have business expertise integrated in them. That means a change of the organization structure must be carried out to enable this kind of fluency in product development. As in any change initiative, having outside coaches can accelerate this kind of change.
Customer development, Lean startup and Lean UX disciplines provide the framework for this mode of working. Coaches and mentors can speed up the adoption process of these techniques.
4. Reporting Impact on Company
i.e. does your team report on their impact to the company as a whole?
This indicator is really only applicable to larger companies. In companies with only one product, reporting on concrete business metrics relating to that product also reports the impact on the company.
What does that mean? Can your product teams put their work in the perspective of the whole company? Do they know what impact do the different options on what to do have for enterprise-wide success?
Why is that important? In order to report on enterprise-wide success the product teams have to know company-wide goals and priorities. When the teams are willing to sacrifice their own goals for a larger cause, the company-wide system will be optimized. There is total transparency in the enterprise on what teams are working on and why and a total alignment to maximize the company’s success.
What if you do not have this in your company?
Company-wide transparency on the company’s purpose and long and short term goals as well as on the work planned and being done is a pre-requisite of this capability. Agile portfolio management or Portfolio Kanban can help in establishing this kind of transparency.
Shared purpose across every team is another pre-requisite. Management 3.0 practices can help build that in your company.
Third pre-requisite is responsible and self-organizing teams. Agile methodologies can help get this kind of mindset started and Management 3.0 practices can help getting self-organization in the whole organization to the required level.
For all this to happen, a lot of changes are needed in the company in individual, team and company level. This is a huge change initiative. Only a few companies in the world (e.g. Valve, Zappos) have achieved this kind of capability.
From benchmarking to Improvement
This set of indicators can be used to set the target condition for the effectiveness of your product company as well. After setting the target condition and benchmarking your company’s current effectiveness in product development it is possible to make a roadmap to reach the desired target condition for product development effectiveness.
This is the way we at Flowa do benchmarking and improvement coaching for product development companies. We have both the technical know-how of how to create great software products and the business expertise to coach your company in product and organization management. We have expertise on all the technical disciplines mentioned in this article as well as all the business, product development and management disciplines needed to maximise the product development capability of your company.
Get Started with Improvement Right Away
If you are ready to take your company’s product development capability to another level with us or if would like to get more details on how we can help you benchmark and improve it, please contact us using the form below!