Agile Series: How we work — Think It, Build It, Ship It, Tweak It
At aFrogleap, we believe that a great user experience is key for turning your brilliant idea into an awesome product. No matter on what device people use your product — on a phone, tablet, desktop, or smartwatch — your customers expect that it is fast, seamless, has intuitive interactions, an excellent design, and provides a personal experience.
But how do we get from your brilliant idea to an awesome product? How can we work together to deliver the best possible end result? And how can we prevent building a product that might look amazing, but isn’t fulfilling the needs of the user? For this, we use an approach strongly based on Spotify’s Think It, Build It, Ship It, Tweak It framework, combining both Agile and Lean principles with our own expertise and experience.
At aFrogleap, we see Agile as a mindset with a focus on collaboration, transparency, responding to change and continuous improvement. Lean, for us, is a disciplined, scientific and cost-efficient method for discovering and building products that people love.
So, how does this work? As you can see in the graph below, Think It, Build It, Ship It, and Tweak It are the four stages through which a product moves in its development. Each stage has its own purpose, and the duration of each stage varies per project. For example, when we already have a validated hypothesis at the start of a project, the Think It-stage could require less time to validate the idea in user focus groups. Iterative Agile approaches are used within all stages, as well as for the whole framework.
Regardless of what project we do at aFrogleap, we start by putting together a small team of at least one designer, one developer and one strategist. Our client participates in the team as the Product Owner of the project and is fully involved in all stages of the process.
The main question to answer in the Think It stage is: Is this product worth building? Not only do we want to create sustainable customer value, we also want to drive down product risk at a low cost. In order to achieve this, our team turns your idea into a product vision using an initial roadmap with objectives and key results. For this, we organise several workshops and create several prototypes — both “lo-fi” paper prototypes and “hi-fi” clickthrough demos or runnable prototypes (using fake data).
When we jointly believe that the product is worth building, this stage ends. Of course, this is a subjective decision with no hard data to support it yet. This hard data arrives in the Ship It stage, so we want to get there as fast as possible.
In the Build It stage, we expand the team to a full Agile Scrum team. (We will further elaborate on this process in coming articles of this Agile series.) As this stage has high operating costs and little risk reduction, we want to keep it as short as possible. The purpose of this stage is to build a Minimal Viable Product (MVP) — as defined in the roadmap — that is good enough to be released to external users. It also has to be good enough to prove something about the product, in order to see that we are on the right track.
It is important to note that the MVP will not be feature complete, but does fulfill the product vision. When we jointly believe that this is the case and the MVP is good enough for real users, we move to the next stage.
When we jointly believe the MVP is good enough for real users, it will be released to a small percentage of those users. Now, we can finally test if the hypothesis defined in the Ship It stage was true, and iteratively improve the product as necessary. It is almost impossible to get it entirely right at the first try, and part of the strength of this approach is that we don’t have to.
When we jointly agree that the product is having the intended impact on the small user group, we gradually roll it out to more users, while still measuring and improving. This gives us time to deal with operational aspects such as hardware capacity, monitoring, continuous deployment, scalability, etcetera.
This stage ends when the product is available to all users.
Note that the product is still not “feature complete.” Finishing the Ship It stage only means that the product (MVP + necessary improvements) has been completely rolled out. There is no such thing as “feature complete”, since the product continuously evolves, even after Ship It.
Now that the product is live and available for all users, we are in the Tweak It stage. This is the most important stage, since this is where all products end up — and therefore spend most of their digital lifetime. Of course, the product has already proven itself in the Ship It stage, but there is always room for improvement. Also, in this stage, experiments and A/B testing can be done. Based on those metrics, it is now possible to add significant new features or small improvements.
At some point, there will be a time when the project has turned into a great product. Most improvements have already been made and — based on the metrics — the cost/benefit ratio of new feature development is less attractive. It could thus be that the product is reaching it’s local maximum. At this point we should try to answer the question: Are you happy being on top of this hill? Or is there more potential in this product and a higher peak to be found? In the latter case, we can start the Think It stage again and rethink the product to reach a higher maximum.
Of course, there are several ways in which we can apply this model to your needs. The aFrogleap teams can be a full service partner, a strategic partner, or a flexible partner. For us, creating customer value through collaboration and transparency is key in creating the best user experiences possible. Send us a message if you’re curious about what we can do for you!