We sat down with our ex-intern Kia Yong to talk about how to better help our clients create a product that balances flexibility and maximizes cost efficiency. 

Kia Yong is currently a final year student at the Singapore Management University (SMU) School of Information Systems. He interned with Tinkerbox in the summer of his second and third year, as a developer, and then worked with our business development and project management teams to improve our processes. 

Q: Will you like to elaborate on the topic for discussion today?

We'll be discussing some of the issues faced by our designers and developers in helping our clients define what they want, or rather, what they need. Our learning is that many clients may have a perfect-sounding idea of their product in their head, but won't be able to flesh out the details of the product, such as what fields an input form should have. 

To compensate for that, they request greater flexibility in their systems, such as the ability to add new fields. However, that flexibility comes at a cost as it introduces complexity that needs to be built into the system and maintained over the lifetime of the product. The long term costs of maintaining this feature of the system is part of what we call total cost of ownership (TCO) and is often understated, and its impact misunderstood. 

Building flexibility into the system is fine if there is a real business need for that flexibility, but if in our example, the fields don't change very often, then the cost for maintaining this flexibility becomes an unnecessary expense that doesn't yield very high return on investment. Smetimes, the field in question has far reaching consequences on features that you want to add in the future. 

Q: So let's break this down. What issues do developers face when having to build more flexibility in a system?

When breaking down each feature, software engineers have to plan and implement safeguards at multiple levels. When a client says "Build me a system that can do <x>", they often have in mind the "happy path", which is when users use the features as intended. They don't think about dealing with missing or incorrect input, or even malicious input (e.g. sql injection, tainted input). A system that does not need to cater to these less happy paths is incomplete at best, if not completely and utterly broken. 

Some of the responsibility for dealing with these issues fall on the developers, like the security implications discussed above. In our work at Tinkerbox, we use software libraries and frameworks that are well maintained and automatically updated to keep in line with the latest security fixes. We also write automated tests to ensure that both happy paths, and various edge cases are handled appropriately. With greater flexibility, more checks must be put into place to ensure that the interactions are working as intended. 

In software architecture, it is important to take a modular approach, where we break down our code into smaller components to manage complexity. Doing so also allows for greater flexibility and extensibility, but also comes at higher implementation costs. Not doing so is a recipe for disaster, as the resulting codebase may not be able to handle the flexibility required, or becomes brittle and prone to bugs. 

At the end of the day, our developers need to help clients understand better the implications for the features and flexiblity that they request. 

Q: What can be done on the client side to better manage the features and flexibility required?

Some clients have greater clarity than others as to how some functionality needs to be fleshed out. When we assess a client's requirement to be more ambiguous, we push them to reduce risk by scoping out a Minimum Viable Product (MVP). The MVP, as the name suggests it the minimum suite of functionality required to take a business idea to market and it should bring value to its end users. 

There are several benefits of building an MVP. 

Firstly, it is an opportunity for the product owners to develop clarity in their vision for the product. Going full-steam ahead without such clarity is probably doomed failure anyway, so it allows the product team to move at an appropriate pace. 

Secondly, building an MVP allows the business idea to reach the market faster, which means that the product team can start collecting market feedback. Market feedback is critical in informing product direction, not just when product owners lack clarity, but also to validate their business assumptions against the real market. 

Finally, a smaller build is far easier to make changes to than larger, more complex systems. There's a saying in software engineering that source code is a liability, not an asset. While that's more rhetoric than hard fact, it makes software engineering sense to prefer more succinct code to verbose code, given both pieces of code achieve the same result. Less code results in lower maintenance costs, and greater flexibility when making changes later. 

Q: And how will you suggest a client goes about creating such an MVP?

Clients need to scope out the features that provide value to their users, and to prioritize them ruthlessly. Failing to prioritize is product management failure.

It will be helpful to all members of the product team if we have a list of user stories that we can weigh based on their importance. Each user story can be said to be a “must have now”, “must have later”, and “nice to have”.

It is always tempting to have everything now, so clients need to fight the urge to categorize all user stories as “must have now”. Good prioritization is critical in giving direction to the product team.

Another dimension that can help with planning an MVP is difficulty. Some user stories are easier to execute than others, so collaborating with the product team to get a feel of each story’s difficulty will help with planning where to direct resources.

Building a good list of user stories and scoring them on importance and difficulty will allow inform the product owner’s decisions, and align them with the product team.


In closing, product owners should not underestimate the cost of not having clarity in their product vision. On top of that, they should avoid building unnecessary features or workarounds to overcome their lack of clarity, as it leads to further costs and complexity. When it comes to execution, scoping and building an MVP will reduce the risks and impacts of bad decisions in light of poor clarity.