Is it Better to Build the Right Product or Build the Product Right? (Hint: It’s Both)

After more than two decades of helping companies from startups to enterprises deliver digital experiences that add value to their companies and grow their businesses, we have a motto:

It’s not just about building the product right — it’s about making the right product.

This means your #1 consideration is your audience. “User-centric design” isn’t just a buzzword. You have a winning combination when you build a product with technology, features, and functions that makes it intuitive and safe for customers to use and solves their pain points and challenges.

So how do you know that you’re building the product and simultaneously building the right product?

The good news is that it’s not difficult when you partner with a product development company that has a few essential tools in their belt, including an Agile approach, a user-first culture, and a DevOps-driven process.

By the time you finish reading this article, you’ll know what it takes to build a product that does it all right, putting your company on the right track for business success.

The “Right” Approach — the Agile Mindset + a DevOps Culture

Software development used to be a relatively rigid process. The Waterfall method didn’t allow for inexpensive or easy iteration. The steps were straightforward: conception, initiation, analysis, design, development, deployment, and maintenance. While all of those stages are important, the emphasis on perfection over progress was costly — financially and in terms of time to market.

Today, the Agile mindset reflects the lightning-fast demands of the marketplace. In our highly competitive world where customers make decisions in microseconds, business success depends on a short time to market and rapid responsiveness to customer feedback. Agile offers a highly collaborative and moderated development process with many implementation methodologies, including Scrum, Kanban, and XP (extreme programming).

While the approaches may differ, the Agile philosophy prioritizes progress over perfection. The “right” product is always one that includes interim tangible releases, early validation from customers, and an ongoing willingness to adapt to change — no matter the phase of development.

A DevOps culture complements an Agile and Product mindset, greasing the wheel and ensuring that all internal teams work together to validate ideas and move releases along quickly and seamlessly. With clear communication and a shared understanding between development and operations, you can count on continuous innovation, deployment, and iteration for faster, automated, high-quality software releases.

Stages of Product Building

You can broadly classify building products in three stages:

• Problem-solution fit: You identify a problem and a viable solution.
• Product-market fit: You establish the product’s market, which is an ongoing process of refining the product and identifying the audience(s) that need your solution.
• Scale: Once the product and market are proven, it’s grow time!

Superficially speaking, the evolution is pretty linear, going from relatively simple to increasingly more complex. However, on a deeper level, there is a common through-line that must be kept central to the process — the user experience.

At all phases, then, it’s important to remember the #1 lesson of product development: you are not your audience. The root of most failures stems from believing that your customers think of the product as you do.

Here are a few critical questions to ask at each stage:

• What is the problem the digital product solves?
• Are there users who need that problem solved?
• What are their motivations?
• Is there any existing solution that solves the same problem?
• Are the users satisfied with the available option(s)?
• Are the users looking for an improvement?

The list could go on, but the point is that these user-centric questions are fundamental to your business success from Day One. And they must continue to be top-of-mind at every stage.

Stage 1: Problem-solution fit

At the outset, you’re focused on the basics of a problem-solution fit: making sure the problem is worth solving and the solution is viable. Keep in mind the challenge doesn’t have to be novel, but how you articulate and solve it does. The goal is to make it faster, cheaper, and/or more intuitive for people to meet their needs and desires.

This is where you build a Minimum Viable Product (MVP), and the key word here is minimum. The outcome you’re looking for is feedback, so you don’t need a full-on coded product to determine viability. We often customize existing technology to quickly and inexpensively prototype a basic version of the concept to shine a spotlight on the solution. So skip the bells and whistles, and keep it simple.

Stage 2: Product-market fit

The next step is product-market fit. Using the insights gathered from MVP users, you build the product. The point now is to test-drive your theories about both the market and the solution. This is where your business can take hold — or fall apart.

For example, a fast-moving consumer goods (FMCG) giant retained us to digitally enhance a popular initiative that had been going on for years in India to empower rural female micro-entrepreneurs. The idea was to support them in selling FMCG products in remote areas at a discounted price with a customized app and website.

However, once we did field research, we realized that the solution wasn’t right for a couple of significant reasons. Most of the women had limited access to smartphones. Moreover, they had a deeply rooted behavior pattern: they relied on rural sales promoters (RSPs) for the entire end-to-end order placement process. We also discovered that the RSPs were backing the whole system’s sales staff presence, ensuring that the rural entrepreneurs they served were well supported.

As a result, we advised our client to evaluate and enhance existing RSP mobile apps instead. The problem that was solved — the business empowerment of rural women — remained the same, but the product created as the solution was completely different.

The outcome you’re looking for at this stage is a more in-depth insight into the customer experience so you can continue to iterate. While field research is great, you can also get quantitative and qualitative feedback from places as simple as user errors spotted in the metadata. That way, the product team will know the error before customers report plus the context. Be sure to capture that information by including a mechanism to schedule calls so that the product team can speak to customers regularly.

Stage 3: Scale

By the time you’ve reached the scale phase, you’ve got the market and the product down. This may sound like an endpoint, but it’s just the beginning.

As with the two previous phases, the iteration necessary to serve your audience the right product continues to evolve. And keep in mind that “audience” isn’t homogenous. You’re likely serving multiple segments, from individuals to varying-sized companies, with different product offerings and price points to match. This is why, for example, on many popular SaaS products, you’ll see a free or inexpensive version, a “most popular” (medium) offering, and a premium option.

By the time you’re scaling your business, you’ll also be using several different tech stacks. Commonly that will include a stack for the core product, one for sales and marketing, and another for support. There will likely be sub-stacks as well. Some of it may be custom-built, and you can rent other aspects of your technology and infrastructure.

Finding The Right Balance Between Product-Solution Fit & Product-Market Fit

While an Agile mindset speeds the process from concept and solution to ensure a product-market fit, on its own, it’s not sufficient when deciding the size and scope of the MVP.

Incremental product development is all about reducing friction with a minimal product in terms of features and functionality that offers maximum value to customers. This makes it quicker and easier to grok the feedback, rework the product, and release an improved version. The cycle repeats until you reach a place where your product is self-sustainable or doing well in the applicable business scenarios. In other words, you’ve achieved product-market fit.

While this sounds like a fast process, keep in mind that it can sometimes take years if the product planning and market research isn’t on point.

Finding the sweet spot between the product-solution fit and product-market fit is critical in your quest to build the product right and the right product. The linchpin?

User-centered design (UCD).

Fusion with UCD

As discussed, your users must be at the core of your development process. Further, you’ve got to ensure you’re continuously solving problems that your customers want and need resolved. When you fuse UCD techniques like design sprints with Agile practices, you can bring the best of both worlds together to engineer a solid product.

Many UCD techniques are available to validate your product idea, from Lean UX to highly qualitative research-based activities. The key is not just to gather user feedback but also to welcome new changes.

At Net Solutions, we implement design sprints using various methods, organized into five phases: Understand, Sketch, Decide, Prototype, and Validate.

1. Understand: User needs, business needs, and technological capacities

Map out the problem space and create a “shared brain.” During this phase, the team comes together to explore the business problem from all angles. Techniques include:

• 360-degree lightning talks
• Competitive overview
• User interviews
• Field visits
• Stakeholder mapping

2. Sketch: Key strategy and focus, exploring as many ideas as possible

Generate a broad range of ideas and narrow them down to a select group. During this phase, individual team members get time and space to brainstorm solutions on their own. Techniques include:

• Crazy 8’s: An exercise where designers sketch eight distinct ideas in eight minutes to create a wide variety of solutions to the problem
• Crazy 8’s sharing & voting: The group narrows the top solutions down.
• Solution sketching

3. Decide: Upon the ideas to prototype

Now, determine what to prototype to answer the sprint questions. During this phase, the team selects from the best ideas uncovered thus far. Techniques include:

• Heatmap voting: The group zeros in on features/ideas that are most impactful
• Zen voting: Ideas are reviewed and voted on in silence
• Decision matrix: Allows the group to base decisions on objective, relevant criteria

4. Prototype: An artifact to test the ideas with users

Build what’s necessary to validate ideas in a short time frame. A sprint prototype is a facade of the experience created by the team in the sketch phase. Techniques include:

• Storyboards
• Interactive prototyping

5. Validate: Idea with users, business stakeholders, and technical experts

This is the moment of truth! Test the prototype with multiple live users and get valuable direct feedback by watching the users interact with the product. At the end of the sprint, there is a recap and next steps. Techniques include:

• User tests
• Stakeholder feedback
• Technical feasibility check

The ongoing assumption-testing and related adjustments can have profound implications. While, in most cases, the work is simply about ensuring features and functionalities have the right space in an MVP, some UCD techniques are so powerful that they can completely change the problem statement.

For example, a global company once tasked us with consolidating their digital footprint in the real estate and construction sector. Over a decade, the client had created several mobile apps and websites for their sales staff to use to sell heavy equipment. The geographic discrepancies were causing inconsistencies in business models, as well as some serious brand concerns.

In the understanding phase of our UCD work, we conducted ethnographic research by spending time with sales reps on the ground in several locations. The more thought we gave to consolidating the digital presence, the more we could see how cultural differences made a consistent sales process impossible. In Asian countries, for example, two to three meetings and discounts were necessary to close deals. From interviews with several top sales consultants, we began to see where and how to improve the digital experience for better sales results.

Building on the premise of on-ground differences in transactions, we were able to work with the senior leadership to devise a strategy that responded to cultural differences but still unified the company’s disparate systems.

Build the Product Right

Responding to users every step of the way relies on fast iteration and reliable innovation. The goal, then, is to build a structure that scales easily over time by taking advantage of automation and other opportunities to streamline your work.

Keep in mind that what’s “right” for your product today will change over time. As the company grows from being a startup to established, the tech stack evolves as user needs and desired outcomes become more complex. Just consider the biggest in the business: Twitter started with Ruby on Rails and moved to Scala. Dropbox launched with Python, moved to Go, and now uses Rust. The list goes on.

Engineering follows suit. Infrastructure changes based on the business stage — from launch through to being an established enterprise — and is also influenced by budget, security, and performance, among other considerations.

Crucial factors for building the product right include:

1. Start with an appropriate architecture for the product.
Be sure to consider the requirements of growth for the next three years and architect it — don’t over-engineer for hypothetical situations that may never occur. Technology evolves, user requirements change, and business models advance, so the architecture will need to be reevaluated every few years (three or less).

2. Choose to use a “boring” technology stack.
While it may be tempting to try out the latest flashy tech, choose the one that the market has proven.

3. Make security a top priority.
Bake security into your product architecture according to the types of users who need access to the system, the features they require, and who needs to use which features. Be sure to create a tight user-role specification so that information doesn’t leak out because a user accessed information that (s)he was not supposed to. Finally, always check for top OWASP vulnerabilities.

4. Follow the 12-factor methodology as the base engineering design.
As drafted by the developers from Heroku, this road-tested DevOps approach empowers you to build a product that can scale on the cloud platform as it gets popular. Even if your product isn’t a SaaS, you can use it as a beacon that lights new ways to consider and deliver the software you’re building, with a spotlight on software erosion costs and systemic app development issues.

5. Include a sound logging system.
The app will be deployed in the cloud and accessed by hundreds of users using many different machines with a range of operating systems, flaky internet connections, an array of browsers, etc. It’s a given that there will be errors that you have not tested for or anticipated. This is why a centralized logging system that records all errors is critical. It empowers you to know about errors and the context of the errors before the users start complaining. A comprehensive log also provides insight into features that need improvement to continue to evolve and refine the product.

Conclusion

We’ve said it several times so far, but it’s worth repeating: the right product is the one that’s right for your audience — their challenges, needs, and desires.

To ensure you don’t let your assumptions and preferences color your work, use a UCD process to road-test your product idea. While your digital product’s success may still depend on the other market controlled factors, including timing, public policies, and unpredictable world events (like a pandemic!), you protect your interests by focusing on a product-solution fit first.

The product-market fit comes over time. Again, the best way to make it sooner rather than later and keep your costs down simultaneously is to stay on track validating the user experience.

Through it all, a methodology like 12-factor app development is essential to keep your build-run-release cycle streamlined and to build your product so it scales easily, without glitches or security issues.

The “right” products are those that employ the magic combination of smart engineering and even smarter UCD processes. If you have questions about what’s right for your business, talk to us. We’re here to do right by you.