Is INVEST always worth the investment?

Sizing features and stories

One of the long-lasting acronyms in product management is INVEST. Going back to the works of Bill Wake the acronym urges us to make sure that stories are independent, negotiable, valuable, estimable, small, and testable.

While in theory intuitive, the guideline practically presents quite often a dilemma. It is often difficult or impossible to reconcile independent and valuable with small. The trickery teams use to overcome this dilemma usually includes breaking down user stories into smaller ones and labeling them valuable by making up some sort of learning to be achieved.

And this approach is reasonable when assumptions are risky and especially the problem is poorly validated. We had such a challenge when we wanted to enable customers to invite drivers to the FINN Business portal. Some interviews indicated they were, but we all know that stated intentions do not necessarily match future actions. We therefore launched a simplified version of “invite a user” before developing a fully-blown user admin interface to test the fundamental value assumption. The stories were small and valuable as we were confident that we would see a change in behavior in the form of driver invites.

On a different occasion, the challenge was another one. We observed that customers passed delivery and driver information as comments upon checkout. This essentially delegated these administrative tasks to our customer success managers, even though our customers could do it themselves after the checkout. So we had a UX challenge at hand where we wanted to see the outcome (change in customer behavior) that more customers enter this information themselves. We decided to design an express checkout that would allow the customer to capture that information as part of the checkout (more proximity = better adoption) with as little friction as possible. Pretty straightforward.

But during refinement, we got stuck in sizing discussions. The team had a strong urge to cut the functional scope and even the design requirements in order to split the story into much smaller ones. Just like it worked for our “invite user feature”.

But this was different. The well-validated problem we tried to solve was a UX problem. The degree of behavior change we will achieve is therefore dependent on the quality of the UX flow we build. The solution was feasible, the required additional effort was reasonable, the alternative intolerable.

One counter-argument was that we would maximize learning by splitting this one feature into several smaller iterations. But I disagreed. If we see poor results from the first iteration, we remain confident that the next iteration improve the results. If we get good results on the first iteration, we remain convinced that we can get even better results with the second iteration. So the second iteration is not really debatable and already defined.

So given that we want to maximize the value by changing observable customer behavior (customers enter the information themselves), I was glad to ignore “small” for the sake of value. The key difference here was the problem validation. The problem was well-validated. We saw countless customers passing order information through the comment field. So there already is evidence that the user wants to pass this information. Even the solution was highly inspired by existing solutions from our B2C department. So the risk was minimal especially compared to the investment.

I am a fan of INVEST and iterative development. But sometimes you should also be fine to push something bigger if you know it is the right thing to do.