In our last article, we discussed the process that we use to build lean products that solve a core problem, or what we call “maximally valued products”.

The goal is to distill the product to its rawest form and release it to the market so users can participate in the evolution of its features. In other words, we reduce the development effort and focus on speed to market so we can get feedback from real customers.

This does two powerful things:

1). It validates (or invalidates) product-market fit. If users love the product, we ask them what else they’d love to see in it. If they don’t like it, we ask them what it needs to make them fall in love.

2). It reduces the cost and time that it takes to build the product — allowing you to focus on the second most critical piece of the puzzle; marketing and user adoption.

In our experience leading tech startups, we’ve found that rapidly releasing a product and iterating based on user feedback is the fastest way to get traction and build a viral growth strategy.

I mean, how can you go viral if you don’t build something that users love? Something that they’d be willing to tell their friends about? Something that impacts them enough that they feel compelled to evangelize?

Or as Marc Andreesen famously said in 2007, product-market fit “is the only thing that matters” for early-stage startups

To dig into that, we ask two key questions: “What does the user want?” and subsequently, “What’s the essence of the product?”

Whether we’re brought in to work on a brand new product or to fix one that’s been completely derailed, we need to understand those two key elements. Without that clarity, we can’t do anything.

‍

Before we discuss features, or a tech stack, or DevOps, we need to understand the core problem that the product is solving. We want to empathize with the end-user and understand the problem so clearly that the solution presents itself.

It’s almost like going to the dentist with a toothache — more than crowns, and braces, and tooth-whitening procedures, you just want the pain to stop. Everything else comes later.

In that way, the product roadmap is shaped by end-users and early adopters — leading to really “sticky” software that users love.

There’s a great statement on the AndreesenHorowitz blog that says:

“Power users are the biggest sign of product-user fit. Making the leap from product-user fit to product-market fit is about listening to these users to evolve your product to attract more users.”

We couldn’t agree more.

That’s why we’ve created a development process that helps build “product-user fit” early on so that you can take the product to market and iterate based on user feedback.

To do that, we use a two-step process to make sure that we don’t waste a single second of development time building something that users don’t like.

The Two-Step Mechanism

We break our process into two distinct phases; the “Discovery Sprint” and the actual “Development Process”.

As you’ll see below, the discovery sprint helps us rapidly define the scope of the project and create a working prototype — typically within a week.

We’ve seen development methodologies become lean and agile, but we haven’t seen companies apply the same principles to the discovery process. Our “secret sauce” is to treat the discovery phase like its own sprint.

The goal is to make the software development process data-driven, and there’s no better way to gather data from end-users than to create something and put it in their hands. This is a concept we learned from Jake Knapp and his seminal book Sprint.

This is the secret to getting the project started on the right foot. Like an architect that creates a scale model of a building, we create a high-level prototype that users can play with.

The feedback we collect from these prototypes is invaluable.

Here are the steps we take to do that:

• Digital Whiteboarding: We didn’t pioneer the term, but we’ve refined it to map out the business motivation and context of the project. The end goal is to capture the essence of the project in a few sentences and then provide a concrete example of the end-state. For instance, the goal would be “Mr. Taco Restaurant wants a backend logistics system to get real-time insight into current inventory levels” The concrete end-state would be “We have XXX amount of tomatoes, so we don’t need to order them”

‍

• Identify Users: We want to identify the 2–3 core personas that will use this app. We want to figure out what they want, what they’re struggling with, and any trends in terms of demographics.

‍

• Create a Process Outline: We’ll then create a high-level flow diagram that outlines the real-world process from start to finish, as comprehensively as practically possible. This document isn’t set in stone and evolves throughout the project.

‍

• Low-Fidelity Sketches: At this point, we’ll have enough to sketch out low-fi wireframes of the product. We’ll also include 1–2 word descriptions of each screen. We call this our “app flow” where we storyboard the user experience.

‍

• Prototype: At this stage, we’re ready to create a prototype based on the app flow. The emphasis is to create something that end users can interact with so we can solicit feedback

‍

• Collecting Feedback: Once we’re created the prototype, we collect feedback from users on how the prototype works. We ask a series of questions to solicit their objective feedback. This is an iterative process, but the prototype is usually close enough for us to begin the development.

‍

The main benefit of these discovery projects is that they’re a means of quick and cost-efficient validation.

Building software isn’t easy, but these discovery projects use a much more malleable medium to shape something and see if it’s headed in the right direction, before investing too much time and money in something that doesn’t hit the mark.

The goal is to deliver a tangible prototype that users can demo and provide concrete feedback.

The end product is a series of pictures that look, feel, and behave like a full-blown app, without actually coding it. The prototypes are interactive, allowing you to go to screens, click buttons, but they’re essentially a series of pictures, linked and configured to behave like a fully responsive mobile app. This is the secret to our entire process.

This isn’t proprietary to us, but we know that many development shops just don’t do it. Other agencies will jump in and build and use the actual product as the prototyping mechanism. The result is that you spend a lot of time and money building something that users don’t want.

Software Development Process

‍

With the discovery project out of the way, we set up infrastructure (servers, domains, hostnames, etc.) so we can deploy a minimal version of the app as soon as possible.

• Create a Working Demo: Our goal is to demo even a very minimal version within the first few weeks. This builds trust and allows them to watch the product take form. We want to demo the product as early as possible because the longer it takes to implement something, the higher the risk that that something will miss the mark. We meet with the client weekly to keep this feedback loop as tight as possible. It allows us to track progress, share updates, and identify risks before they derail the project.

‍

• Creating Feedback Loops: We want the customer to see results as quickly as possible so we can create a tight feedback loop that guides the project. This feedback loop is the secret to a successful software implementation. We’ve found that the biggest factor that hampers software projects is the lack of communication between the developers and the users. It becomes a costly game of telephone that pits the users and developers against each other. As we get customer feedback and build things out, we’ll create a high-fidelity prototype that’s closer to the end product. It’s a visual, tangible, concrete deliverable that the customer can interact with, and provide feedback on.

‍

• Defining Stories: We’ve found that creating stories helps describe the functionality of different parts of the app. The stories closely track how the personas would interact with the app. For example, an admin user would want to see if users have activated their accounts. We’d create a story description that says “When I do X, I want to see Y.” For example “When I go to the dashboard page, I should see a list of employees that have logged in with a timestamp.” We describe the persona, the business justification, and the steps to make it happen. We use stories to gain sympathy and an understanding of the user. There are different ways to define features, but we feel that stories allow you to put yourself in the position of your ideal user. That way, the user can guide the project even when he can’t provide direct feedback.

‍

• Budgeting: Once we’ve defined those stories, we’ll run through a “budgeting” exercise where we estimate and assign points to tasks. Efforts of small, medium, large, and extra-large. Based on our experience from past projects, we calculate the points and estimate what we can get done within six weeks. This process helps us prioritize the most important features for the MVP. It’s like shopping for groceries at the store. The budget is the 6-week timeline, and the stories are the groceries that we need to buy within our budget.

‍

From there, we’ll create mocks for new features. Many companies skimp on this step and rush straight to building without taking design and UX into account.

We want to create a deployable asset as soon as possible so they can release it to users in six to twelve weeks. If it takes any longer than that, we start looking at features that we can add in future iterations. Again, the goal is to create a usable product as fast as possible.

We schedule weekly check-ins and ensure constant communication to maintain integrity and transparency. This protects the project from scope creep and helps us identify unforeseen project risks.

This is the core of an agile development process and is exactly what we did when we ran a startup. Like a tech startup, these “sprints” help us identify hiccups, issues, and obstacles so that we can quickly make adjustments.

We provide budget updates so that they’re aware of how changes in scope and functionality impact the overall budget of the project. The goal is to keep you integrally involved in the project week in and week out so that you can eventually take ownership of it.

But the core of our process is to define the minimum amount of effort necessary to yield maximal value for the client.

A tight focus on a core product through discovery sprints allows us to pivot based on changes in project scope, unexpected risks, and a constant reorganization of priorities.

‍

A working prototype is the cornerstone of the product roadmap. We then prioritize and iterate features into the core product based on feedback.

This is exactly what we did in the startup world and it’s what we do with our clients now.

Whether you’re a consumer-focused tech startup or an enterprise company building an internal tech product, the process is the same. Keeping your focus on a product that elegantly solves your end-user's problems is the common thread.

Check out part 1 of this article, “The MVP Redefined” where we break down what makes a “maximum value product”, click here.

‍

‍