PRODUCT EVOLUTION DRIVES USER ADOPTION THROUGH THE ROOF

THE CLIENT:

Our client is a global investment and consulting leader, specializing in commercial real estate and property management. Their consultants serve organizations of all sizes, across industries, all over the world. The client worked with Geneca to design and implement the first release of a new application for the budgeting and funding of multi-year utility projects within an organization. After a successful launch, and several months of production usage, the product was ready for evaluation and evolution.

THE BUSINESS NEED:

The new application is used by 4 different stakeholder teams who perform different actions on a utility project as it works its way through the funding process. In the initial release, we advised the client to keep the workflow very simple and flexible because they were transforming a manual, serial, business process into a digital cloud-based solution designed for concurrent, collaborative work.

The first release we delivered with the client is what we call a ‘minimum lovable product’. It had the capabilities that all of the teams felt were the most important in greatly improving how they do their work. The goal of the first release was to allow the teams to adapt to a new way of doing work together without a lot of system constraints. The teams loved the first release.

It hit just the right balance of new, concurrent, capabilities, added visibility to the state of all of the projects, and had some guides to help them with their process flow.  After the first 1,000 projects had gone through a funding cycle, the teams were bursting with new ideas for the next release.

WHAT GENECA DID:

The product manager needed our help to define and deliver a set of enhancements to fit their product evolution budget. The client wanted to keep the focus on the user experience so that adoption would remain high among all of the stakeholder groups.

We collaborated to find the best approach to manage the feedback and provided an inventory of the work to be done. We also grouped the features into related sets to allow the development to be done in a cost-effective way. This enabled the product manager to understand the costs of the features and weigh that against the business benefit to evaluate and prioritize.

The product manager was able to settle on the right mix of features that were delivered by the time they were ready for the next utility project funding cycle.

THE RESULTS:

A successful evolution release and high user adoption! Some of the things the client learned and valued when we worked together to transform and evolve a manual process involving several stakeholder teams into a digital one:

(1) In your first release, focus on the outcome of the work not the process – make that better for each stakeholder team!

• Listen to each team involved in the manual process and understand what they create, produce, and deliver to the other teams.
• Focus on the result of their work not ‘how’ they do it in their manual process.
• Listen to what makes it ‘hard to do work’ in the current manual process but don’t try to ‘automate’ or fix the manual process. (Your users can usually tell you what is wrong with what they do today but may have trouble envisioning a different way to do their work.)
• Implement big wins for each stakeholder team in your first release.
• Set an expectation that you don’t have all of the ‘answers’ in the first release and that you’ll be adjusting as you learn.

(2) Consider a user-managed workflow in your first release so your teams can ‘discover’ new ways to work

• If you can avoid it, don’t build a system-controlled workflow in the first release. Your users will find the best ways to get their work done if they have some flexibility to figure it out themselves.
• Allow each team to ‘set a status’ based on the completion of their work and enable all users to see the status of the shared work items.
• Limit the ‘status’ types to the number of stakeholder teams who participate in the shared work. They may want to have lots of states. Each team only gets to choose one and the meaning of the status is ‘our team is done with this one and it’s ready for the next team’.
• Make your status types ‘Action words’. Each team should have a unique word or two that describes their completed work and enables the next team to know it is ready for them– e.g. Proposed, Analyzed, Authorized/Not Authorized, Budgeted/Not Budgeted. If a decision occurs within a team that enables another team to take an action, then there should be two statuses from that team such as ‘Authorized and Not Authorized.
• Build some simple notifications if teams want to know when a shared work item changes status – make the notification specific to ‘who wants/needs to know’.

(3) Focus on smoothing out the process and high value/low cost capabilities in the first evolution.

• Your stakeholder teams will now have a much clearer picture of how to leverage their new tools and can describe where to build in system support for their work process. They will also have a list of capabilities that will help them do their own team’s activities.
• Separate features that will smooth the process from features that will help individual teams. This will enable you to keep your primary focus of the first evolution on features that will improve the flow of the work – that will have benefit all of the users and drive adoption.
• Manage competing requests from individual teams by having each team sort their features into 2 buckets – ‘Big Value’ and ‘Nice to Have’. If time permits, allow a representative from each team to present their list to the rest of the teams. You will find that a feature for one team may have additional value for another. They will also have suggestions for things that the other teams could do that would improve their work.

(4) Work with your development team to create an estimate and approach so you can build your evolution plan and present it to your teams.

• Allow your development team to make suggestions on the best way to implement and help them to help you make cost effective choices.
• Make sure you include some ‘Big Value’ features for each team in the release so that you can continue to build momentum and adoption across all of the teams.
• Include your teams in selected retrospectives throughout development.

(5) When evolving a product, deliver something of value to each of your stakeholder teams even if the focus of the release is on the overall flow of the work.