The Three Lenses of Innovation - What not to build.

What Should We Build?

For a long time, one of the biggest constraints in software development was the question: Can we build it?

The answer depended on the complexity of the requirement, the skills available within the team, the technology being used, and, most importantly, the time and resources available.

This often meant that companies had to make difficult decisions about scope. Features had to be prioritised, requirements had to be simplified, and at times, expectations had to be limited simply because something could not be built within the available constraints.

With AI now becoming an integral part of software development, the “How” has become significantly easier.

Give an AI coding agent a prompt, refine it, keep iterating until you get what you want, and the feature is ready.

This is already changing the way software is developed. Development timelines are shrinking, costs are coming down, and teams are able to build significantly more with the same resources.

The sky is the limit. Almost anything you can imagine can be developed.

Want an elaborate chat system? DONE.

Want payments integrated into your system? DONE.

Want an animation of birds flying across the screen when the user logs on? DONE!

You are only limited by your imagination (and the limits of the AI agent you are using).

But if anything is possible, what should we build?

The question has now shifted from “How to build?” to “What to build?”

Product decisions are now more important than ever. With teams shipping features almost every week, what to build next is a question that several companies are struggling to answer.

“Sir, there are two options for the user flow. Which one should we implement?”

“Why not... both?”

And this is where the challenge lies.

When building something is no longer the biggest constraint, deciding what is worth building becomes far more important.

So how can companies decide what their next feature should be?

The Three Lenses of Innovation

Desirability, Viability and Feasibility.

Desirability - Is the feature something that the customer really wants? Is it solving a pain point?

You don’t want to create a solution that needs creating the problem as well.

Viability - Does it align with the product? Does it align with the company? Is this something we can sell and earn money from?

And lastly, Feasibility - Can we build it? Is it possible with the resources at hand?

This is the part that is changing rapidly. What was once a major constraint in product development is becoming less of one. We have significantly expanded what can be built.

We, as innovators, need to find the sweet spot - the intersection amongst the three.

Build customer-centric designs. Start building what the customers want, not what the management wants. The management is rarely the customer.

It is very important to steer development in the correct direction. Just because you can develop it, does not mean that you should.

Make smarter product decisions.

Hence, we at Hexasphere don’t believe in being the “yes” man for the customer. We will resist if we feel that a feature is unnecessary or unnecessarily complicated for the customer.

We make products that the customer actually wants.

There is a concept in software development which says that your product is mature not when there are too many features that have been added, but when there are no features left to remove.

As the ability to build continues to expand, the ability to decide what not to build will become equally important.

The goal is not to build everything that is possible. It is to build what is valuable, relevant and necessary.

At Hexasphere, we believe that good product development is not about adding more features. It is about making better decisions about which features deserve to exist in the first place.