Why delivering features is not enough

Features are good but only if someone is actually using them. So instead of focusing on delivering as many features as quickly as possible it is better to focus on learning what is the product your customers need (note that need and want are often not the same thing) and do it (learning) as fast as possible.

Why is it so hard?

Before joining TransferWise I worked for about 10 years as a consultant/developer in software service companies helping other companies build stuff. I found it quite hard to apply these ideas about learning and impact in practice. I believe it requires different thinking on organization level to stop taking software development as something that is about delivering features and ideally as many as possible with as little cost as possible. Indeed it seems to me that outsourcing generally doesn't make value driven development any easier but quite the opposite. When your starting point is a fixed budget and predefined solution all packaged into a project with fixed deadline then it's just much easier to focus on optimizing these project parameters not actual results. Especially when the time between finishing the project and actually seeing the impact is quite far apart.

Feature is not value

Now although features and value might seem like something similar then in practice they can easily conflict with each other. Developing new features is crazy expensive but the tax they add on future features and modifications is much worse.

So how to do it then? In TW no team measures its successfulness by counting how many new features it has shipped. Instead each team has a purpose and a KPI to help tracking progress. For example the purpose of our team (Conversion) is to make moving money for users as effortless as possible and we measure ourselves by checking what is the percentage of users who successfully transfer money out of all new users coming to our site. If we implement something new that doesn't change the needle then we kill it.

Speed up the learning

But how to avoid building features that are not needed and more importantly how to speed up the learning process? The key is to build as little as possible and then get feedback. In the past our team relied mostly on A/B tests. However, even though we have quite a lot of traffic on our site then the feedback cycle of a typical A/B test is still too long - typically around 2 weeks. Also you need to build not perhaps fully fledged functionality but at least quite big part of it in order to deploy it to users.

User testing to rescue

One way how to get feedback sooner and iterate faster is via user testing. For that simple UI prototypes are often enough. The key value of such UI prototypes is that they allow us to iterate very fast - several times during a day if needed. However, even that may not be enough if the starting version is very far off. Hence for more complex new things our team uses the Design Studio Methodology to involve whole team (devs, product lead, customer support contact, designer) and come up with a set of ideas that our designer can use as a starting point. We still use A/B tests and other quantitative analysis tools but this is mostly for verification.

Maturity Model

I think this matches very nicely with the 3 level developer growth model I like to use for measuring developer maturity. Starting level is where your main concern is getting stuff working (delivery). Second level is where you start focusing more on getting stuff done so that you can be proud of how it's done (mastery). Finally, third level is where you focus on finding ways how to reach the goals by doing as little as possible (purpose).