MYOB is a software business. It prides itself on helping companies manage their business and accounting needs. But for a software business that aims to save its customers time, and simplify their business back end, MYOB’s own back office systems were not up to scratch – particularly its invoicing system.
The system was originally designed to manage around 40,000 customers. Now it serviced wayyy more businesses than that and was creaking at the seams. While the large majority of MYOB’s customers still received the correct invoice, some didn’t. As Katie says:
“It simply isn’t okay for an invoice to be incorrect, particularly if you’re invoicing for software that, in itself, generates invoices.”
As product managers responsible for the invoicing system it was up to Katie and Paul to lead the fix. For this digital transformation project they had the usual constraints of cost and resources but also extra demands of speed and a very low tolerance for errors (as the whole program was about reducing errors).
Lessons from the digital transformation
As they started planning the project they quickly realised how difficult it was going to be. It wasn’t just that the invoicing product, or invoicing system, was complicated, but so too were the business processes that fed into the system. As Paul said, they realised they couldn’t be both fast and accurate at the same time. It was going to be a trade-off between the two. In managing this trade-off, and the business transformation, Paul and Katie learned three main lessons.
Lesson 1: When transforming complex systems, simplify business rules to remove complexity.
They realised that a lot of the complexity in the invoicing system was caused by the complexities that fed into the system. This made it a much bigger job than simply changing a product, they also needed to change the business. To get buy-in for this expanded remit they showed their stakeholders, through good data, that the complexity was hampering the business. Not only hampering the accuracy of the invoicing, but also increasing costs and reducing the speed of any changes and speed to market.
Lesson 2 – Tell stakeholders (both before and after) that it’s likely things will go wrong.
Katie and Paul briefed stakeholders, upfront, that due to the speed and complexity of the transformation errors were likely. This was all stakeholders, both internal and external, including customers.
They started to set regular stakeholder meetings where they set out their approach, exactly what would happen and the impacts it would cause. As part of this communication, they explained that the initial change wasn’t going to be a big bang launch with everything perfect and beautiful. They’d iterate after launch, continue to improve the system, and fix any errors.
Despite all the complexity, the messaging about errors, and the speed – the initial launch went brilliantly! They migrated the first small batch of customers, with no visible errors. They celebrated! They had cake! And then, the next day, an error emerged…
Lesson 3 – Fix fast, take responsibility, maintain momentum.
A small group of customers received two invoices. While few customers were affected it did cause them quite a bit of confusion and there were also flow on problems within the business. Straightaway, Paul and Katie took responsibility and set out to fix the error. They also got all the necessary groups within MYOB involved, from customer service to PR to tell customers about the error and explain how they were going to fix it. Paul says that was a pivotal moment in the whole transformation: “we did lose trust, but I think that we showed we were serious. We showed we were invested in doing this. We weren’t mucking about. That idea of breaking eggs being necessary to get to an omelet, that really came home.”
While stakeholders had been told that mistakes were likely, for many of them that didn’t really hit home until the first issue. Thankfully, due to the way they had built internal support, the CEO continued to back their approach, understanding that occasional mistakes were part of the tradeoff between speed and accuracy. From there, Katie and Paul continued to build momentum, regularly delivering new updates and additional functionality, for example an automatic feed through to finance. They also kept up regular communication with stakeholders, so everyone was aware of their progress. This way, when mistakes happened it was easier to keep people onside as they had built advocates in different teams within the company, who knew what was happening and respected the work they were doing.
While the digital transformation isn’t complete, Katie and Paul are now confident that transforming the invoicing system will be completed quickly and well. As Paul says:
“At the end of the day, working software is the best proof that what you’re trying to do really works.” They have shown that digital transformation can be both quick and accurate, but it’s essential not to get bogged down by mistakes. When things go wrong you can stop, roll back and get stuck in recriminations. Or, you can keep going, maintain momentum and make things better.
From the Town Hall
After every episode we hold a town hall meeting where members come together to discuss the content of each episode, ask questions, and get help and advice from our product experts. Here are the main takeaways from this town hall.
An app is not a strategy.
Companies, and product teams sometimes fall into the trap of thinking that a new app, website or feature is a strategic goal. It’s not. What is a better strategic goal is progress towards the customer problem, or business objective, you’re trying to achieve. Part of the allure is it’s easy to measure whether you’ve delivered an app or not. It’s easy to impress people with fancy new technology. But solving customer problems and making people’s lives better is hard. It’s hard to do and it’s hard to measure. But that’s where we should be striving.
On managing stakeholders.
Often a multi-pronged approach is needed for stakeholder management. You can have large regular meetings with all stakeholders, but you also often need smaller catch-ups where you brief smaller groups in-depth and answer their questions before the major meeting. This reduces the chance that big meetings will go off track and helps build support.
Getting senior execs or important stakeholders to come to product showcases/presentations -where you’re actually demonstrating your product – can also be a great tool. It helps them better understand your product and why you’re doing things and saves a lot of time in reporting, additional meetings and communication pieces.
Quick vs good.
One of the disservices that Agile practice has perpetuated is that faster is better and more is better. And in fact, what we really need to do is to deliver something of value, and then iterate on that to get it right. This might mean that other things won’t get delivered in the timeframe wanted, but you get one thing done really well. This creates value, and allows you to move onto the next thing. It’s about being outcome focused, rather than ‘output’ focused.
On marketing pressure to release features.
Many product managers get pressure from marketing teams to release new features. Marketers often want something flashy or new to help sell more products. This can be a problem in companies that are marketing-led rather than product-led. We need to turn this around and ask marketing what makes them think they’ll sell more with this feature? How many units will they sell, and why? This puts the onus on marketing to demonstrate ROI.
When product teams are kept busy making small feature changes to satisfy marketing, or other stakeholders, everyone is so busy making small changes they don’t have time to make the big seismic changes that really generate value for customers and profit for the business. To move away from this is tricky. The key is to get stakeholders on-board with the long-term vision for the product, what you’re aiming for 1-2 years from now, not in 3-6 months’ time.
Making the most of customer feedback
Getting high-quality customer feedback is crucial in product development. But if you’re not getting the right type of feedback, not understanding it, or not doing anything with it, then it can be useless or even counterproductive. Customers can get annoyed if they think you aren’t listening to them or acting on their feedback.
If you do have a customer feedback forum where customers can directly enter their problems, it’s important to have some way of ‘upvoting’ the most common problems. This gives you a better sense of which problems are widespread, or very important to your customer base.
It’s also important to have a way of digging further into your customers’ problems, to truly understand them. This can be through approaching customers directly to find out more about their problems and exactly why they are causing pain. You can also force customers, or internal stakeholders, to put their problems in a specific format, like a problem statement eg.
Finally, you can take things further than a problem statement and ask people to talk about the things they CAN’T do and explain the PAIN this causes them. This can really force people to explore their own feelings and explain their pain points more clearly.