Think It, Build it, Ship it, Tweak it

Back in 2017, at aFrogleap we believed that a great user experience is key for turning your brilliant idea into an awesome product. Your customers expect that no matter on what device your product is used — on a phone, tablet, desktop, or smartwatch — 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 as best as possible to deliver the best possible end result? And how can we prevent building a product that might look amazing, but is not 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 the focus on collaboration, transparency, responding to change and continuous improvement. Lean, for us, is a disciplined, scientific and capital efficient method for discovering and building products that people love.

The process

So, how does this work? As you can see in the graph below — “Think It, Build It, Ship It, and Tweak It” are four stages in which a product can exist. Each stage has its own purpose and the duration of each stage varies per project. For example, when there already is a validated hypothesis at the start of a project — less time could be needed in the“Think It”-stage to validate if there is a need for the idea in user focus groups. Also, iterative Agile approaches are used within all stages, as well as for the whole framework.

‍

Think it‍

Regardless of what project we do at aFrogleap, we start by putting together a small team with at least a designer, a developer and a 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, as a team we turn your idea into a product vision with 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 demo’s or runnable prototypes (but with fake data for example).

When we jointly believe that the product is worth building, then this stage ends. Of course, this is a subjective decision with no hard data to support it yet. This hard data comes in the “Ship It”-stage, so we want to get there as fast as possible.

‍

Build it‍

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. Also it 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 it does fulfill the product vision. When we jointly believe this is the case, and that the MVP is good enough for real users we go to the next stage.

‍

Ship It‍

When we jointly believe the MVP is good enough for real users, it will be released to a small percentage of all 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 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 role 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 and scalability, etc.

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 100% rolled out. There is no such thing as “feature complete”, since the product continuously evolves even after Ship It.

‍

Tweak it‍

Now 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 — and based on the metrics it is now possible to add significant new features or small improvements.

Re-think it‍

There will come a time in the future that the product is great. The most improvements are made and — based on the metrics — the cost/benefit ratio of new feature development is less attractive. It could be that the product is reaching it’s local maximum. At this point we can 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 Re-Think the product to reach a higher maximum.

‍