(Reading time: 4 minutes)
For many, this subject is counter intuitive: Get the product we develop into production as soon as we can, and doing it often. Let our team breathe fresh air.
Pushing hard to get something out the door can feel unprofessional. We are professionals, and our job is to come up with great solutions to problems. The issue is, that we have a whole series of biases working against us – our own biases and other’s. Going into production will help us handle these biases.
Not being in production is like swimming under water. Not until we are in production, do we break the surface and have fresh oxygen enter the system. Only in this case learning is the oxygen. Continuous learning about our users and their problems, learning about our team itself and learning about the corporate context that the team is likely to operate within. Taking every opportunity to poke at the assumptions we all make.
Just as we need to breathe, our products need to be in production. It is like “a law of nature” of digital that we cannot ignore when creating our product roadmap.
Fight Assumptions!
The biggest assumptions we make are related to what users are actually willing to do. An example: Me and a dear colleague of mine were once called upon to consult with a budding startup, at an early stage. Their idea was to combine retail and charity, but I will spare you the details. The team was stuck, preoccupied looking into the business model, diving into the details of agreements with different brands, and how to technically create a product of internet scale. Our final advice was to setup a simple website, where their offer was presented, and where consumers could register their email address to receive offers – everything marketed according to the ideas they had (which at the time was Facebook). If no-one registers, let’s not spend more time and effort. If people register, it is well worth handling them manually while the product is developed. Get into production, and get that first do-or-die assumption taken care of – breathe fresh air!
So, is having a fake website live being “in production”? To me, being in production is about having real users, using something that they perceive as the real deal, to solve problems or satisfy needs. But naturally, being in production has little value if we do not monitor what people are doing with our product and what user behaviours it evokes.
“If you are not embarrassed by the first version of your product, you’ve launched too late” – Reid Hoffman
We have to make assumptions, we just cannot afford to have them lingering. Going into production will provide us an exercise in humility. Placing us eye-to-eye with the reality that we just cannot know for certain what is going to solve our users problems. We turn our assumptions into hypothesis’ on how we can create value. But not until we see users real reactions are we breathing fresh air.
Learning About Users
I get pushback on this subject from designers and UX people, stressing the importance to learn cheaply and pointing to methods like User Research, User testing and Prototyping. This is all very relevant, and these are indispensable tools. However, what I have seen is that often the limitations of such tools are not fully understood and create a false sense of certainty and can easily turn into a hindrance of learning further down the line. It is not either/or, it is both. I don’t see a contradiction here. So what are those limitations?
Often User Testing is done by calling a test subject into a room, having the situation/problem in which the product is intended to be used explained to them, and then asked to try to solve this problem using some sort of a prototype. The issue is that when we place a person in this kind of situation, they are not really experiencing the problem that the product is trying to solve. For them personally, what is often more important is to give the testers what they are looking for. To make a good impression by providing clever feedback and trying to avoid being overly critical and not hurt anyone’s feelings. This does, by no means, render User Testing useless, but it can be a real challenge to peel off these layers of uncertainty to get to the reactions of a real user.
One anti-pattern many can relate to is when a pre-study is conducted, using all the above mentioned tools, ending up with a prototype that everyone feels really excited about. This is all well, but the problems start when this is used as a blueprint to get funding for running a project to build the thing. This project becomes a quest to realize a backlog of features to a specific date, effectively stopping all learning. No-one really wants to break the design that the company has invested so much in. Our designers’ pride rides on it. It will make you instantly unpopular with management. The unspoken goal of testing can quickly turn into confirming the design.
But as a side note, beware! The reverse is also an anti-pattern. Being in production, it’s tempting to design by numbers only. A clear product vision should solve this problem.
Another very important benefit when being in production is that learning about the users becomes a natural part of everyday work for the entire team. Knowing the users is no longer the territory of designers and UX people alone – it is everybody’s business. This drives the motivation within the team and is an absolute necessity in order to exploit the innovative powers of the entire team. The entire team should be in the business of cater for user needs, not building features.
We are working with assumptions and everything we come up with will need to change. The sooner we get it out, the sooner we know in what ways it needs to change. Breathing fresh air.
Learning About Ourselves
Having a well-functioning cross-functional team delivering value to users is no small feat! So many things need to be in place. Ideally, the team should be like a well oiled-up production line, with a short turn-around time from coming up with new ideas to deploying features for users to actually use. How do we best know if we have everything we need to make this happen? We go into production to prove the value of our delivered features early and often. This is Lean.
The goal is to optimize the process of turning business hypothesis into technical solutions that provides value to users, then start learning from users actually reactions. We aim to make this process as fast as possible, enabling us to conduct experiments and ultimately out-experimenting our competition. With Amazon making double digit deploys in production every minute, this can be a tall order.
Any team has a lot to learn about themselves and their context in order to make this happen. And this learning can only be achieved by actually doing it; utilizing the principles of Lean. Good stuff, like reducing batch sizes and limiting work in progress, which can be a real challenge to our intuition. Some designs for new features celebrate their first birthday before development is even started. Have we really not learned anything relevant in that year?
Learn about our dependencies. Too often dependencies on external parties of our team is what will kill our productivity. If our success depends on tasks in other team’s backlogs, we want to make absolutely sure that they will not hold us up. I advocate being a trustful person, but always prefer seeing it work in real-life to a mere promise!
Similarly, within the team, we want to see that we do not get tangled up handing over tasks among ourselves. Reducing the lead-time through our process, requires the team to collaborate intimately and for everyone to get fully engaged. Soon this will empower our team members to make decisions and contributing real innovation to the product.
Shaping the Almighty Roadmap
If our thinking is that we can run a pre-study to come up with a blueprint for the product, then build and launch, we are impeding learning. Swimming under water. A Roadmap expressed in terms of features and not user needs will inhibit learning. If you are having difficulties to incorporate continuous learning into the Roadmap, you need to try harder! It makes sense to swim a few strokes underwater, but software is a long haul, we need our oxygen.
I will leave you with an inspiring anecdote on the subject: A retail client of ours wanted to provide their on-line customers with product recommendations in order to increase sales. Straight forward.
However, they set the ambitious goal of having this functionality live within 8 weeks! A brave promise, only possible to make because they had a very workable Plan B. They were willing to recommend random products in order to get into production sooner. Even this extremely scaled back solution would allow learn about how customers interacted with the recommendations and how to improve that interaction. Also, while doing this, the team made sure that all data necessary from other teams was available. For me, this shows that even if it might seem difficult, bordering impossible, by taking “going into production” seriously and thinking a little harder when you create your Roadmap, it really can be done.