If software product adoption is the house, users are the key. After a product launch, organizations are often surprised when a new product doesn’t deliver the expected results.
While in some cases, adoption may remain high when software product success is lower than hoped, understanding your user communities and how each one’s role contributes to your products’ success will help you to involve them at the right point in the product lifecycle. As organizations dedicate resources toward understanding user communities, they are often faced with the following questions: when do we engage users and how do we choose which user to satisfy?
Understanding Product Stakeholders (Users)
Today, the term “stakeholder” dominates the corporate lexicon. Broadly, it is a term that describes everyone who has a stake or interest in the software product’s success. Yet, there are many different types of product stakeholders, or users, who perform very different functions. Product teams often believe they understand who their product stakeholders are and when to involve them in the software product lifecycle. If the users are typical (and there is only one type), that may be true. For enterprise applications that serve more than one user community, it can be challenging. Let’s look at the different types of stakeholders.
- Inventor (or Business Sponsor) Stakeholders
- Digital Strategy Stakeholders
- Financial Stakeholders
- Technical Stakeholders
The flow of involvement of each stakeholder starts with the inventor, or business sponsor, who has the vision for the product. Next, the digital strategy stakeholder delivers the market, user and competitive research to confirm the viability of the software product, as well as the business needs. A financial stakeholder is typically engaged early in the process, working to help fund the business case. Also, a technical stakeholder often partners with the product owner with feasibility, design, approach, plans, costs, and more.
Companies face the competing needs of multiple users every day – plagued by limited budgets and tight timelines – while racing to get their products to market. When multiple users are interacting with your software product with different needs and perspectives, how do you choose? Here’s an example scenario:
A company is designing an application that will be used by a management consultant to help the client choose a benefits provider, restructure their company, or evaluate a portfolio strategy. The users may include the client, who has to provide information about their company and/or review the results of an analysis, the provider of the information, which could be coming from a 3rd party, and the management consultant who is advising the client about how to use/understand/interpret the information. In this case, there are at least three user communities – the client, the consultant, and the third party. When putting together the first product release, which user to do you choose to satisfy?
The best solution is to deliver a product that improves the work experience of all 3 users. Yet, if you have to tip the scales to one user type in order to test your product, here is a question you can ask:
Can my software product succeed if this user doesn’t use it correctly?
In business, many products that have a user community who either are required to use it because it replaces a current product, because of a corporate mandate, or because it ‘enables’ the consultant to deliver their service. This means that your product could have high usage and still suffer because the other user communities didn’t get the intended results. To ensure successful adoption and correct usage of the product, keep these things in mind:
Emphasize early involvement: It’s important that users are involved in the early stages (invention phase) of the project to get them to adopt the product and use it the way you intend.
Incentivize adoption: Many motivations that can compel a user community to adopt a product and use it correctly, but it has to be something that improves their work experience. If the solution is not built into the application, then a motivation to use it correctly needs to be external to the application – financial incentive, strengthen their brand, opportunity to gain new clients.