Building a (Minimum-Viable) Product

It starts from the strategy.

Apr 20, 2017 · 5 min read

Back in April 2016, Martin and I spent 5 weeks building a really simple web prototype — an online marketplace for construction equipment — for B. Using that to bump ideas off his personal network from the construction sector, B decided to build TREX officially, with the goal of digitalising the physical buying, selling and rent of equipment.

The Beginning

When we got to building the “real” website, Martin and I got back to the drawing blocks. After many close consultations with B, we started listing out all the features that we have to build so that we can come up with a timeline. We came up with the list from whatever we could think of or referenced from other sites, while cutting out on features that “were not entirely suitable”. The list continually changed, and grew.

When we felt that the list was exhaustive enough, we got down to building the navigational flow and the databases. We projected to complete these in the next 6 months:

Features: User accounts, user listings, profile page, enquiries/chat, bookmarks, company profile page, team account, search page.
May: Navigational Flow + Database Exploration
June: UI Sketches + Database 0.1 + Database 0.2
July: Front-End Coding
August: Tie up front and back ends

Needless to say, we overshot our timeline, with only Martin coding both the front and back ends, while I did the visual designs. Clearly, we were inexperienced not only in how the system should be designed, but also in project scheduling.

Reassessing Product Development

You can’t just split the project into front-end and back-end and estimate a timeline for each section. We botched our initial timeline, but we learnt to scope our project.

So we looked at all the features again, and prioritised them according to “importance” of the feature — what we deem as necessary for the users. We better estimated the time needed to build each feature based on its scale. We also followed a Waterfall-liked development workflow, prepared to adapt it as we come along in a bid to stay true to ‘agile practices’. And we set to complete it by the new year.

Now, that makes 7 months of development altogether. With more accurate scoping, did we get it right this time? Hardly. We shipped out a functional product that was far from complete. Well, no products are ever complete, but it was not exactly “minimally viable”.

Reviewing ‘Scope’ and ‘Prioritisation’

At this point we have also renamed the marketplace as i1Machines, while TREX remained the name of the company. Our team (that has expanded to 3 people) also ran a round of internal user testing to find problematic pages, which Martin resolved in two weeks. The site was mostly ‘minimally viable’ save for a few bugs and incomplete features.

This time, Martin and I decided to go with a product roadmap, Trello-style. We could break down each feature into multiple parts, each part to be completed in a one-week “sprint”. We assigned tags to each feature/task to define the type of task. The tasks were further sorted into Current, Near Term and Future Term, as a means of prioritisation.

We further complemented the above roadmap with a calendar view of the tasks and scope. This became a really handy tool that we used to check back on each week to make sure we are on schedule, and the rest of the team readily knew what each of us were working on.

However, it took a lot of effort to constantly check back on the roadmap and to drag and drop the tasks. It would also be useful if we had a physical version right smack in our face to constantly remind ourselves of the tasks.

Where Is The Strategy?

Although we have been practicing prioritisation in the product development, we did not explicitly state the basis for the priorities. We “knew” that it was necessary to have a credit system but did not state its purpose. We “agreed” that a corporate profile page was necessary for a business user, but did not state how exactly it would benefit the user.

Strategic reasons lay behind each of our decisions, and not writing it down created a lot of ambiguity within the team. For a particular feature, each of us could have interpreted it differently. It was only through our most recent roadmap (that took the form on an excel sheet) where I stated the strategic objectives, did I realise this.

We had different ideas of a corporate profile page, which led to us prioritising its need and task complexity differently. Only when we discussed its strategic purpose, did we agree upon what it actually should be.

When the team grows, it is especially important for the strategy to be laid out as the different fields of user researchers, business developers, and marketing executives all have their respective priorities.

It Starts From The Strategy

On hindsight, many of our decisions (not just in product development) would have benefited with clear strategic objectives in place. Should we take on a particular investor? Should we hire a front-end developer?

Defining the strategy helps to align the team. Do we all agree that a particular action is necessary at this point of time?

Defining the strategy helps simplify solution. Is this the ‘minimum viable’ that we can create to achieve our objectives?

Defining the strategy helps define the measurables. What should be measured, and were the strategic goals achieved at the end?

Let me know your take on strategy in the comments below or give a ❤ if any of the points resonated with you

.April: We’re now touching up on our user interface before heading to Open Beta in May.

Update, August: We have opened up access to i1Machines. I have written about how we use the MVP as a validation tool, and how we are moving on from our MVP.

The Startup

Medium's largest active publication, followed by +479K people. Follow to join our community.


Written by


A crypto writer who researches and charts cryptocurrencies for investing and trading. Author of Rolling In Crypto.

The Startup

Medium's largest active publication, followed by +479K people. Follow to join our community.