97%

Toward the end of 2019, I was transferred to a new team at Toyota Australia, the Toyota Used Vehicle Platform. I would be the Scrum Master and UX Designer. We were tasked with bringing an improved experience to our visitors, and look to incorporate financial repayment options for these used vehicles.

The used vehicle site had been suffering from neglect. A product with great potential, but little attention.

I was incredibly lucky, the Product Manager involved gave me, and a super talented full stack developer(Andre) pretty much free reign, under one constraint; all vehicles that would be eligible for a finance option, i.e. a weekly repayment cost, needed to be live by March 2020. Whatever we wanted to do to improve the experience at the same time, we could.

So, Andre and I took huge advantage of this. We story mapped the exisiting site, using the Information Architecture as our starting point. From there, we could easily prioritise the biggest opportunities, and make plans on reducing risk and increasing our delivery speed.

The biggest question on our mind, was, how could we quickly and easily give visitors a weekly repayment option, if not on all cars, but a small subset? There was some complicated criteria for some of the vehicles, as to whether they were eligible, so we needed to find the quickest way to market.

We looked to firstly consider the user journey, make it easier for the user to “window shop” cars. We then considered what the business wanted, which was essentially more email leads being sent from our site straight out to all the Toyota dealerships around Australia. Finally, we thought about how we could pair back the design, only give the user the basic/essentially details, and in turn, make space for the financial repayment data to come into the design.

This was what we started with:

Our main assessment of the experience, was how unclear it was for the user. What were we asking them to do next? Once a user was scrolling, did we want them to click on a car, get their own car valued, or what?

We paired the UI back. We focused on making it clearer what we were asking the user to do. Essentially, we wanted them to enquire about a vehicle as quickly as possible, or look into the details of a vehicle a little more closely.

Once we arrived at the above UI, we got to work on the financing options available for our visitors. We wanted to get this out safely, but fast. We assessed our options and decided, the first release, would have the financing option display only when a user clicks on the “View details”. Through this approach we would test the stability a new API to one car at a time. If we could get that reliably working, we could increase the capability from there.

As we increased the financial repayment options on the UI, we continuously refined the experience, continuously stripping out unnecessary features, making it much more succinet and less demanding.

After testing our approach on a subset of vehicles, and increasing that subset incrementally, we built confidence in our product. If we caught bugs, wrote tests and ultimately released a stable new Used Vehicle experience.

All of this resulted in some amazing analytical results for a team of essentially two. Over a 6 month period, from Jan 2020 – June 2020 we saw a 97% increase in traffic and a 35% increase in user generated enquires as compared with the same 6 month period in 2019.

It astounds me what you can do with a tiny team, some trust from above and autonomy to get the job done.

Stories, users, and the art of slicing!

Stories, users, and learning

This month I had the pleasure of spending some time with Neil Killick(http://agilemelbourne.neilkillick.com/) and a few others learning all about story slicing. 
It was incredible. Yes, I realise, that’s a fairly strong statement, but I don’t think I’ve been in a situation before, where I’ve been able to apply so quickly what I had just learnt. 
I’m very fortunate to work for the best company in the world, literally, Salesforce.com has been ranked #1 by a whole heap of evaluators around the global. That means, I’ve got the space to try new things, and my colleagues are open to working in different ways.
Within hours of this session, I was able to take what Neil had taught us to work and apply it. Where once I had struggled to know what to do with a story, I feel I can now take it to the mincer and slice it in several ways to make it more feasible for everyone.

The following Monday following the session with Neil, I was sitting down with my team running a sprint planning event. During the session, we considered several “user stories” to take into the sprint. Having Neil’s guidance, I could, within moments, look at a story write it up on a whiteboard and apply Neil’s magical “Seams” approach to story slicing. I could quickly help our team break down our work into manageable chunks. By doing this, we could then focus on conversations about where we would be trying to add value. 
Not only could I help our team look at a story from a capability perspective, but when it came to implementing a solution, I was able to slow the team down from jumping behind the first solution that made sense. Thus, slicing the story from a functional and technical perspective. This allowed us to instead, do something Intuit are renowned for; going broad before going narrow.
Following on from reading Eric Ries latest book, The Startup Way, I did some Google hunting for Intuit. They have this approach to ideas. Rather than getting behind a single approach, they spend time thinking up as many possible ways of solving a problem before going deep on just a few. From Neil’s session, I was able to initiate a level of discussion that didn’t end abruptly by everyone getting behind just one option. We took some time to consider alternatives, which in the end actually led to a completely different solution being implemented then was thought of beforehand. This has saved us a least a week of time if not more, as I’m confident, if we hadn’t considered as many options as possible, we would have been a week or more into building a solution, only to realise a better way! We found this better way much sooner, or at least our degree of confidence in the way we are building out the solution now is higher and ultimately more considered.
Inside of learning about functional and technical slicing, Neil taught us a technique he refers to as the Hamburger method. It’s a simple approach to functional and technical slicing. I won’t go into too much detail, as you can experience it first hand by attending a session(here), but it’s a great tool for getting your team to hold off on jumping straight into one solution and to consider a multitude of alternatives. 
Since this session, I’ve noticed an improved confidence to take a statement or vision that an executive has for their project, and slice it up. This will help our team to start looking at quick ways to deliver value. I have found in the past that getting the backlog into a healthy state has been hard. One of the specific problems I’ve faced is initiating a backlog and getting it to a point of being “ready” for a build. I’m not saying by any means I’m all of a sudden perfect. But the ability to slice has helped take a statement/assumption and show how we might leverage it to give the development team something to look at and work with. This, of course, has meant, we can more quickly establish our priorities and build something. The benefits for me are huge, it means we’ll be at a point sooner rather than later where our team can inspect and adapt what we are building. 
Thanks, Neil!