One of the most popular theories around building a tech product or service is what’s called the Lean Methodology. The Lean Methodology says that it does you no good to sit around in a backroom developing something until it is absolutely flawless, only to release it and find that none of your users are interested in it or understand its purpose. Instead, Lean says that you should build a minimal viable product – something which has the essential functionality, but with a few technical flaws and rough edges – and push that out. The purpose of this is to get feedback from your users. The theory being that if it is the users you are building the product for, it is the users who should be driving what the product looks like and what it does. The upside of this is obvious, more user feedback means a better ultimate product and greater user adoption when you finally do launch the finished product. Yay Lean!
However, there is a certain amount of risk associated with the Lean Methodology. The obvious risk is that users don’t always appreciate how the process works. With Lean there is no safety net so to speak. If a user has a terrible experience, sure you will get feedback, but it is unlikely that the user will return to try the product again. Thus, you run the risk of losing quite a few of your early adopters who will not wait around for you to fix the problems. Even more of a risk, if a user has a terrible experience they may go out and tell other potential users not to bother trying your product. Additionally, it can be difficult to work out why users abandon your product if there is no good way of collecting their feedback.
So, is this initial loss of users worth the feedback you gain?
Let’s look at an example from our own website. Initially, we designed our login form to ask for a username and an email address – your temporary password was emailed to you and you were automatically logged in. We did this in an attempt to get people using the platform as quickly as possible by logging you in immediately and getting you working on it. What we ended up doing was confusing a whole lot of potential new users. Some put in an email address and a password instead of a username, and then were quite angry to see their password pop up as their username. Quite a few more were simply confused and frustrated by the process altogether. The long and the short of it is that we lost quite a few initial adopters because we were rushing to push out a minimal viable product and get feedback.
Now let’s return to the initial question: is the loss of a few initial users worth the feedback you get?
My answer would be yes. With any methodology you have to accept that there will be a cost. In this case I think the cost is worth paying. You will get this feedback eventually, and it is better to have it early when making changes is relatively simple, than to have it later when you have been through years of development. That said, it is also important to stop and think about what you are doing before you push it out. Don’t be in such a rush to get feedback that you miss some of the obvious pitfalls – as we did with our login form. One way you can help to mitigate this is by conducting AB testing sessions where you put various versions of the product out and compare them. This type of testing is not always possible but provides good feedback. Another alternative we are using heavily right now is structured users sessions. They are time consuming and the sample size is not as great, but it can be a good first step in the process.
To sum it all up, Lean Methodology is certainly the way forward when designing a tech product. Feedback is a powerful tool that will help you to build the best possible product with the best chance of succeeding, and if you have to lose a few users along the way, well, that is just the price you pay. Just make sure you are also using the most important tool of all: common sense!
by David White, CEO