Having been a part of 20+ early product teams, I've seen far too many projects fail before launching. Each failure was unique, but there was a general theme: ideas were valued more than practicality.
There was often talk of grand ideas, but rarely was there a strategy, plan, or data suggesting the concepts were valid. It almost seemed like the goal wasn't to launch but to continue building some illusively "ideal" product.
I've since educated myself in the ways of the lean startup, agile methodologies, and other similar approaches, which have helped keep the current product we're building as minimal as possible. The problem we were facing was that the app still seemed far too large.
We're working on a spreadsheet-centric application, which makes our task of producing an MVP more complicated. If we built a basic spreadsheet software from scratch, it could require hundreds of thousands of dollars, which is money we don't have.
As we grappled with the disparity between our ambitions and budget, solutions started to emerge. In this post, we'll prioritize practicality, as I'll be sharing the three most effective tactics we've been using to drastically reduce the costs of bringing a complicated product to market.
TLDR; We're involving users in development and removing all non-critical features.
Any credible post on the topic of minimum viable products (MVPs) will tell us to include customers in the product development process. Without them, we can't produce an actual MVP.
We initially had all kinds of ideas about the problems we could solve for users. The sheer number of features on our list presented a big problem, because we didn't have the resources to deliver everything – nor would it be a good idea if we had the money. What we needed to do was reduce our roadmap drastically.
The general process we used to shape a leaner product looks something like this:
Our intention with this process was to interact with the market as quickly and inexpensively as possible. The demos we created were just static images stitched together, which required no coding.
We could then use the data we collected to inform our prioritization decisions.
To illustrate the choices before us, we used a well-known product management tool called the value vs. effort matrix, which compares our feature options based on two critical factors.
In the matrix above, four distinct quadrants classify features according to levels of value and effort. Our goal is to maximize the number of high-value features (top half) we deliver based on our available budget.
The trouble with large projects like ours is that there were still too many high-value, high-effort features we could build, which meant we needed to make some hard choices.
Instead of making these decisions on our own, we went back to our waiting list and asked them to rank each high-value feature by importance. The hope was that a common theme would emerge based on a specific problem we could solve.
Luckily, our original hypothesis was well-defined enough that the results for the top 3 features were almost unanimous across all the respondents. The number one feature, in particular, was the most agreed upon.
We took the information from our responses and then refined the final mix of high-value features based on what we thought we could successfully deliver.
As a result of conducting these exercises, we've increased the likelihood of building a product people will want while significantly decreasing the scope of work.
Now that we have a clearer picture of what to build, we can turn our attention to how we'll make it happen.
TLDR; We're using a suboptimal tech stack to accelerate development.
Looking for savings in our tech stack is probably the most controversial tactic we're using. Here, we are making a conscious choice to sacrifice tomorrow for today.
If successful, our product could eventually be less scalable, less performant, and require significant re-investment to rectify later on. I'm willing to make these sacrifices because I'll consider it a win if we get to the point where the issues become a bottleneck.
Making suboptimal technology choices has its limits and can be counter-productive, but if done strategically, it can also enable us to multiply our efforts by many orders of magnitude.
In our case, technology choice has two main budgetary multipliers: the availability of existing solutions and talent (more on this later).
When I say "existing solutions," what I'm referring to is the ecosystem of libraries and tools we can integrate with our product to provide out-of-the-box functionality.
Technologies have communities, and these communities often specialize in certain areas of development, so our choice of, say, a programming language, can dramatically impact the tools we have at our disposal.
For our project, this meant finding a solution to one of the most significant development risks we were facing: the spreadsheet itself.
As it turned out, there were many "data grid" libraries available in JavaScript that met many of our basic needs. We now had the potential to add one of the most complicated features to our application instantly.
It's not all sunshine and rainbows, though, because we'll still have to customize this library, but it's better than starting with nothing.
As I've already mentioned, there are many drawbacks to using libraries, especially for such a seemingly critical feature, so it may be worthwhile to lay out my thinking on how we can decide when it's appropriate to use a library.
To illustrate my point, we'll return to the value vs. effort matrix from earlier.
The features we can identify as candidates for libraries generally reside below the value axis, emphasizing the low-value, high-effort category, which is where our spreadsheet functionality resides.
Finding quick solutions for low-value features means we can spend more of our time getting the high-value features right because they are the ones we'll likely need to build internally.
The second area where technology selection has a significant impact is the available talent pool from which we can choose. If we select popular technologies that have large developer communities, then it should – theoretically – be easier to find qualified talent. While searching for candidates, we'll just want to keep one thing in mind…
TLDR; We hired based on competence, not “cost”
When runway is a dominant concern, it can be tempting to do some back-of-the-envelope math to determine how much we can afford for development.
It is generally good to be budget aware, but in the circumstance of hiring a developer, it's not that straightforward.
Working closely with developers over the past seven years has taught me a lot about how challenging it is just to achieve a basic level of competence. Even with the simplest web applications, there are a number of systems working together, each with its own dedicated field of study. There's far too much for any one person to know.
The breadth of knowledge and skill required is partly why developers vary so significantly in their abilities. What may take a mediocre developer 4 hours to complete, a great developer can often do in a fraction of the time with fewer bugs, tests written, and a problem solved no one even knew about.
We simply don't have enough funding for a less capable developer's mistakes, learning curves, and limitations. The only way we’ll successfully launch an ambitious, high-quality product is with the help of someone great.
Once we understood the need to prioritize competence over “cost,” all we had to do is find someone good, which was an entirely separate problem.
