Inhouse logo

Inhouse playbook

Last updated:

Stay lean and focus on the solution, not the paperwork.

Our Process

Years of experience have taught us that some traditional software development processes don’t always result in great products.

You’re likely just as familiar with the Waterfall and Agile strategies of development as we are, given their popularity. But there are some core problems with each style:

Waterfall software development takes a long time, relies on a ton of up-front planning that might not even pan out, and you only perform testing and validation once a full prototype has been built.

Waterfall development:

Requirements --
              Design --
                      Development --
                                   Testing --
                                            Deployment --

This means if your initial planning wasn’t perfect, you’re likely going to have a long road towards re-calibrating to figure out what went wrong.

Agile software development has become the popular choice amongst development studios, and introduces a more iterative feedback loop between stakeholders, testers, customers, and developers, with the goal of quickly creating a usable product.

However, a third strategy — Lean Startup — we’ve found to be far more robust that fixates on business-oriented goals.

Introducing Lean Startup

——> Ideas ———> Build ———> Measure ———> Data ———> Learn ———> Repeat

Lean Startup combines agile and waterfall strategies with customer development as it encourages “rapid experimentation” over “elaborate planning.”

It has a three-step Build, Measure, Learn process.

While agile tests the product against users. Lean Startup tests the product against the market.

The key concern of Agile is to avoid creating a product that doesn’t work. The key concern of a Lean Startup is to avoid creating a product that people don’t need.

The Challenges of Lean Startup

  1. Rapid Experimentation and feedback are essential but don’t replace the founder’s unique insight, grit, and strategy to win over a market.
  2. Overemphasis on shipping an MVP to Persist, Pivot, or Perish. It’s very hard to discern what is the minimum or viable part of the product, leaving most to give up too early on the idea.
  3. Many argue that MVPs are incremental product features instead of delivering a substantial breakthrough, which customers won’t know by only testing out an MVP.
  4. The focus is mainly on the product and not enough on growth or traction channels.

It’s important to note that as businesses evolve so do our learnings. We take the good aspects of the methodologies above and introduce frameworks we think can complement each project.

We create processes that avoid:

  1. Creating a product that no one wants, or will pay for.
  2. Communication issues, time zone delays, and culture gaps with overseas workers.
  3. A need for a “perfect” plan.
  4. Taking months to get a prototype in the customer’s hands.
  5. Only validating the idea once the final product is built.
  6. Focusing too early on an idea when a bigger problem/solution could be out there.
  7. Developers making decisions without you.
  8. Costly and clunky design.
  9. Excluding stakeholders from shaping the product.
  10. Producing a product that is final and doesn’t allow for changeability.

Instead, we want to achieve:

  1. Quickly validated ideas at low cost through customer discovery and surveys.
  2. High awareness of your business problems.
  3. Extracting a clear vision and making sure the problem exists with your customer.
  4. Find product market fit quickly, and focus on ideas that you know are winners.
  5. Getting validation and customer feedback early and fast.
  6. Putting a functional product in your customer’s hands and iterating from there.
  7. Identifying the best ideas early and focusing on creativity.
  8. Bringing developers and business owners to the same table.
  9. Building a product that can easily be built upon and changed by future developers.
  10. Applying resources into avenues that have the highest likelihood of creating scalable and repeatable business.

We took what we have learned over the past 10+ years in software development and business methodologies to create our own custom formula and is tailored to each project.

Let’s focus on just one question:

How can we concentrate our minuscule resources on the highest likelihood of creating scalable and repeatable business?

If we really think about it, the most important part of the question is the “highest likelihood” part.

Think about how a scientist tackles problems. They can never actually prove anything in science, instead, they work hard to falsify things.