It's Time To Talk About Product Development in Age Services

Building and maintaining a product for the aged and community care market is difficult for a multitude of reasons, some being the speed of regulatory change, expectations from customers, and differing views on clinical best practice.

For software vendors, the engagement with industry and customers is very important, and I highly recommend building a supportive user group of different types of users as a sounding board for any new change or feature that you are planning or releasing. As with any product, not everyone will be one hundred percent on board, but by using that group the standard 80/20 rule should apply.

Developing partnerships with industry partners allows you to be ahead of the curve on regulatory and industry changes so that you can plan and resource those changes effectively. Maintaining a regulatory compliant product is resource heavy and very costly, with many vendors spending up to half of their research, and development budgets a year on just staying in the game.

While I am not a fan of road mapping by democratic process, as customers often don’t fully understand what they need, being able to effectively communicate to customers what is coming, when and what isn’t coming and why keeps customers informed and engaged. Deciding what to build and when is difficult and there are many methods that vendors use, but all of them require data to help make those decisions. That data may come from surveys, product usage statistics, co-design sessions and suggestions from users.

Features can be suggested by customers, from internal development or as part of the sales process, and those features are added to the backlog or some other feature list. A backlog is a giant ranked list of items that have usually had some analysis performed on them. Simply ranking items is not enough to be able to decide what to build, so we use weighted matrices to assist us to help make the decisions.

Different weightings are applied, for example that the feature matches the product strategy or a goal that has been set (OKR). These weightings are applied to the top items on the backlog and help the items that are a best fit to be developed float to the top and be identified. Regulatory items are managed outside of this process as they have fixed delivery dates and are mostly a ‘must do’, an item that we can’t decide not to deliver.

For users of a product – when recommending features to a software vendor, try not to deliver a set solution or ask for a specific change, but to discuss what the problem is that you are facing.

If your product includes clinical features vendors require clinicians to have input on the features and workflow in order to achieve the best uptake of those items. If you do not have clinicians as part of your company, reach out to the same user group described above and find interest from the existing customer base to create a clinical advisory. There will be a lot of opinions and expectations, but with some skill and analysis functionality can be designed and developed to encompass all clinical users.

For customers who are going to market or are implementing a new product need to also understand that implementing a system is going to require change that is outside of product development. Some of the reasons I have seen a product fail have nothing to do with the product at all but are:

• Training has been inadequate
• Change management wasn’t managed effectively in the organisation
  • Transition from one system to another
  • Resistance to learn a new system
  • Not ensuring users understand why the change is occurring and the benefits from that change
• Lack of senior leadership support
• The expectation that a product is a magic pill to internal organisation issues

Often the solution to the above is for customers to log a change request for the system rather than change their internal systems to match the product. At one of my former companies, we would provide implementation discounts if the prospective customer was prepared to take the product ‘out of the box’ due to the significant cost to customer and implement to a customer’s existing processes.

There is a cost to customisation not only for the prospective customer in the form of money, but a resource cost to the software vendor. Customisations take time away from being able to build the core platform to be the best it can be for all users and should be avoided where possible.

For those involved in product development for the aged and community care sector, the challenging environment provides stimulating and rewarding roles where the output of the work improves the lives of not only the end users, but the clients and residents as well. When software vendors involve all parties who use or are impacted by software as part of their product development process everyone wins with more usable, sellable solutions.

Kyle Stewart is Product Manager – Australia with Person Centred Software.