Lean manufacturing is not a new phenomenon. Based on the principles of avoiding unnecessary waste and amplifying quality, the underlying concepts of lean manufacturing trace a path through history as far back as Henry Ford. A second philosophy – agile software development – shares many compatible ideas with lean manufacturing. The agile manifesto, developed in 2001, stresses importance on human interactions, and high responsiveness to change across short development cycles. In the software development community, combining both approaches can be highly productive. Eliminating waste, responding to change, and focusing on finding and developing what has real value often results in rapid development of high-quality software.

It’s easy to see how both approaches can benefit new a startup. With a fledgling business, time and money are resources that need to be wisely spent. Lean and agile provide mechanisms that focus on value, stopping you from wasting time and energy on something that ultimately isn’t going to solve a problem.

At this point, many of you are probably asking yourselves: isn’t that obvious? In retrospect, it is very obvious, but as developers we sometimes don’t think this way.

Less Build Time, More Time Learning the Problem

Consider the fact that engineers and developers are often very eager to start building a solution – we really are problem solvers at heart. Don’t get me wrong – this is a great quality that we share as builders. Ultimately however, building a solution isn’t the best first step to take when it comes to establishing a business. In fact, building first can often lead to a lot of lost time, and end in failure of the startup. This is a lesson I have learned for myself more than once. For me, the process usually works like this:

1. I have an interesting idea (at least to me).
2. I start building it.
3. After burning up lots of free time, I usually find that I have a solution in need of a problem.

While I learn a great deal of tech related things each time I do this (which has benefited me professionally), I fail at the aspect I want most – to create a business of my own. This is because I didn’t concentrate on what was important. As developers and builders, we need to reign in this build first desire, and instead focus our energies on discovering if the problem is painful enough that other organizations need a solution to it, and are willing to pay for one.

Twenty-One Days

I am rather proud of myself and my team when it comes to Sentiment Radar. When the problem of extracting actionable information from product reviews originally came up, it was easy to start thinking about how we would structure a service. As a developer and engineer, my thoughts turned to SaaS platform problems:

• How would we handle security?
• How would we scale with the number of users?
• How would we deploy our application in the cloud?
• What technologies should we use?

Recognizing this desire to build prematurely, we put those problems aside. To be fair, each of those thoughts address good and valid problems, but all of them were future problems that would be nice to have. Until we had a product, building a solution to those problems was really just a waste of our time. Instead, we dug deeper into the heart of the problem.

First Iteration

We approached our problem definition over several iterations. When we started out in our first iteration, we had a simple hypothesis: that sentiment analysis was valuable to a developer or business owner. Running with that, here’s what we did:

1. We identified several popular products that were quite different from one another, but were fairly well known by a large number of people.
2. We created a simple visualization of sentiment data that we collected by hand for each of the products.
3. We reached out to a few trusted developers who we thought could use our data visualizations to help them improve their products.
4. We presented our visualizations to those developers, and asked for feedback.

Immediately, we learned that sentiment analysis alone wasn’t good enough. Just seeing that 89% of the population was happy with the product didn’t really help anyone. Seeing the trend over time was useful from an overall brand / company health standpoint, but there was nothing that immediately told them what they could do to improve things.

Second Iteration

Our discussions from the first iteration had uncovered an interesting story – one developer had scanned through reviews of their product to understand what general areas people were unhappy with. With this knowledge in hand, we created a second hypothesis: that performing sentiment analysis on themes that were recovered automatically from the text would reveal actionable information. For this second iteration:

1. We went back to our hand collected data, and identified themes.
2. We counted the positive and negative sentences we saw for each theme, and generated a new visualization with this information.
3. We widened our audience to talk to, presented our new visualizations, and asked for feedback.

Our second set of visualizations got a number of people excited. The information we presented was actionable – businesses could use the information we presented when planning out a new product, or when looking to refine their existing product. This was good! But for others, we still weren’t presenting enough information. Additional feedback told us that they wanted to know how they stacked up against their competition.

Third Iteration

We now knew at least one hypothesis was maturing nicely. But we wanted to know whether or not a head-to-head analysis was going to be useful. So, for our third iteration:

1. We picked a competitor product to one of our original three products, and performed the same hand analysis.
2. We came up with a visualization that would show the relative strengths and weaknesses of the two products when compared side-by-side.
3. We showed this new visualization to various audiences.

At this point, our feedback was quite positive. People were interested in what we were doing, to the point where we were getting serious inquiries about using our data in real life situations. We felt we knew enough about what people wanted to see, along with what groups we should talk to. Importantly, we were also starting to understand what audience we should be presenting our work to, and whether or not that audience actually had the ability to pay for our future service.

Summing It Up

When we finished our third iteration, we had a minimal visualization system that we could easily re-purpose in a live production service. We went from idea to production deployed in 21 calendar days. More importantly, we distilled our idea over and over until we got to a point where people were interested and excited by it. We knew that our problem was real, and that people would be willing to buy our solution. Only then did we consider building a limited live version of the product.

But fighting our build first instinct shouldn’t stop now that we have a well defined problem. At each stage, we need to take a step back and ask ourselves whether building something will help solve our problem, or if we are just working to build something because we want to build. We need to learn what the problems are, refine our ideas, show it to customers, and then build it.

Work the problem first, then build the solution. Fight the build first desire.