One Size Doesn't Fit All
Juggling different granularities; The risk of interrupting Jobs To Be Done
“Hello”, said Otter, “I’m very hungry, can I please order a hamburger?”
“Hello”, said Eager Beaver, “Before we talk about your order did you know we have an App now? It’s very nice! You can order hamburgers from anywhere!”
“That’s lovely”, said Otter, “But can I order the hamburger right here and now please? It is late and I’m so very hungry.”
“Oh, no you cannot”, said Beaver , “now that we have an App, you cannot order here, you must order in the App. Have I told you how nice it is?”
“Yes”, Otter said wearily, “and I would love to see the App later, but I’m quite hungry right now, and I would just like a hamburger please.”
“In that case,” said Beaver, “you should start downloading the App right now! Once you have downloaded the app and created a profile, and chosen your local restaurant, and added your credit card, it would be my pleasure to show you how you can order a hamburger.”
“No thank you”, sighed Otter, “I’ll just go buy a slice of pizza across the street.”
Customers don’t come to our productivity services because they love our software - they come to do a job. They log on because they need to pay an invoice, or post a job, or send someone a message, or register a status change, or find a critical bit of information.
They often only log on to our tool at the moment that they know they need something from us, and they know exactly what they are looking for - and they often has an expectation of how much time it will take.
When they come to our service, and we break their expectations - we make doing that job more difficult. Let’s say that a worker is logging on to your system in order to download an expense report that must be loaded into their accounting system today. They do this every month on the last Friday of the month. Here are few scenarios (from least bad to worst) that changes can disrupt this flow for them:
A new report type is supported! When the user goes to the place where she usually finds the Expense report, she see one new additional report that wasn’t there before. No impact
What’s New! A pop-op appears on their screen telling them about all the new exciting changes that happened since they last logged in. Some of these might even be interesting changes, but right now the user is on a mission, so she simply closes the pop-up. Mild annoyance
We need you to update your profile! The system requires that all users must have their MetaGoogsoft ID saved in the profile. Upon login, the user is redirected to their profile and has to add their ID before saving. This is mildly irritating if the ID is easily available, but it can be deeply frustrating if the user doesn’t have access to the ID right now or needs to detour to other systems to retrieve the ID. Irritating
We’ve improved our dashboard and menus to be more streamlined! The user used to go to Data → Reports → Expenses to get what she needs, but there is no data menu option anymore. Now the user is lost - the path that she knew and was comfortable with has been taken away, and she has to start clicking around and exploring the world to figure out where her report has gone, and she needs to do it now. Frustrating
Expense reports have been merged into a general Accounts Report. The tool that the user relied on has been taken away from her. She has to find the new report and then figure out how to convert that new report into a format that she can upload to her current system. She basically needs to create a new process to run each month. Oh, and she needs to figure this out today to hit her deadline. Infuriating
My argument isn’t that we can’t change flows or organisation within our app. Our software must continue to grow and evolve, and there are always going to be some people who will be disappointed by our changes.
But it’s helpful to understand that different changes can have different costs to the users.
In a prior post we spoke about batch sizes, and showed the math behind how to optimise your batch size.
Often when software development talks about batch size, we are discussing the value of dev ops, and the value of pushing code to production as quickly as possible. The lower we can reduce the cost of shipping (through automated testing, continuous deployment, etc.) the faster we can ship code to production, which reduces our risk and cost of deployment.
However, deploying code is just one form of batching. Feature releases can also be batched. If you are going to be making significant data hierarchy changes that will force users to learn new patterns, it may be better to batch all of those changes up in a single release rather than drip feed the changes over a longer period.
For a customer - the Fixed Cost of a new Feature is the disruption - they are being interrupted in some way and cannot continue to do the job they intended without addressing the disruption (whether that is as small as closing a pop-up to as large as re-learning the UX). The Holding Cost is still that has been created but is yet to be released.
Your approach towards feature batching should be based heavily on considering the Fixed Cost for a given feature.
An overly simple model that I’ve used in the past is:
If the change is additive (you can still do A, B, C and D, but now you also have E) then release it right away. Users may not understand E or why it’s there - but E isn’t in any way blocking their ability to perform task B, which is why they logged on in the first place.
If the change impacts how a user performs A or B, then slow down. You should minimise the number of times that you interrupt Jobs To Be Done, and batch up similar changes together in a larger release so that you only interrupt the customer once.