Product Development Risk Reduction: A Guide for the Risk Averse

In the tech industry, we’re all familiar with that daunting adage: 99% percent of startups don’t make it to launch. There is hope, however, if you’re exploring product development risk reduction.

One of our specialties here at Goji Labs is taking on what we call rescue projects — projects that didn’t work out with another developer, and therefore, never made it to launch. This article is the first in a four-part series in which we share insights on product development for the risk-averse, covering common points of failure among rescue projects and discuss how they can be avoided.

Begin with risk reduction.

Startups can take risk-reducing steps right from the beginning of the development process, starting with choosing the right people to build their product. Depending on what they choose, startups who don’t assess their needs correctly run the risk of either not keeping up with their own technical needs or over-spending on a technical co-founder they’re not ready for yet. How do they know what’s right for them? The answer depends on their product’s core value and who else is competing in their target market.

Product development risk reduction requires innovation.

Sometimes, a company’s success depends on constant innovation and its ability to incorporate new research and discoveries into its product. Google Search, for instance, relies on an algorithm that Google is constantly updating and improving based on new data. In other words, Google Search’s future success relies on an algorithm that doesn’t even exist yet. When a product’s value lies in the technology itself, startups need a technical co-founder who will be around to maintain, update, and continue pushing their product into the future.

Most companies, however, have less complex technical needs.

What made Uber so disruptive to the transportation industry, for instance, had less to do with its core technology than the idea itself. The Uber app uses existing technologies such as mobile location services and queues for handling pickup requests and assigning drivers to riders. Although Uber’s scale complicates its needs, the core value of its business remains the idea itself. In cases like this, startups may only need a technical team to get them to launch.

Both options come with benefits and sacrifices.

A technical co-founder may cost more, but they constantly work to improve their product and keep it competitive in the marketplace. Startups who don’t need this level of attentiveness after their product is built can save money by contracting their software developers and putting their resources toward sales, marketing, or other needs. When startups can identify what’s right for them, they’re already on their way to a lower-risk development process.

Recently, we began a series about “rescue projects”.

That is, projects that didn’t work out with another developer, and therefore, never made it to launch. We’re discussing the common points of failure between these types of projects and how to properly conduct product development risk reduction. In this second post, we’ll cover the earliest mistake we’ve seen startups make — not fully communicating the vision for their product.

Rescue project clients often tell a story like the following.

In the initial planning phase, they conveyed a high-level idea of the project to their developers who then created spec documents with user-types, features, pages, etc. Maybe their developers asked a few clarifying questions before presenting them with an estimate. From there, they continued into the development phase, assuming smooth sailing until launch and not communicating too much in between.

Although a spec document does allow developers to scope and build a product, it rarely gives them a detailed enough picture of what their clients want. But many developers will build an entire product using just a spec document, which means their clients are spending valuable resources on a product that may only vaguely resemble their vision. Then, instead of launching a finished product, startups have to figure out what’s possible given their remaining resources. Can they salvage what they already have? Do they start from scratch?

Startups can avoid this point.

Startups can avoid getting to this point with a careful planning process in which their developers are actively involved in brainstorming how the final product will look. When we sit down with our clients, we draw out every possible layout, every possible screen, and user flow in order to get a clear picture of their vision. This enables us to draw up wireframes and make a full game plan for the development phase.

When startups involve their developers in product mapping and decisions, they not only give them a very clear picture of their needs but also benefit from the developers’ product experience. Perhaps some features they’re proposing are superfluous or perhaps they’re missing an essential piece of the user experience. Whatever the case, startups only stand to benefit from looping their developers into the planning process, even considering the extra time cost.

Building scalable products.

We’ve already covered finding the right developers and making it through the development phase with minimal risk. For our last post for this four-part series on digital product development risk reduction, let’s discuss what happens after startups make it to launch. How can startups ensure they’re putting a product on the market that can grow as their business and user base does?

Product Development Risk Reduction Requires YAGNI Principles.

One of the guiding principles in building a scalable product: YAGNI, or “you ain’t gonna need it.” It’s the same idea behind a minimum viable product — don’t build more than you need before you can get your product into the hands of users. This idea helps prevent growing pains for startups in two ways. First, it ensures that startups save their resources for features users actually want rather than features they might end up scrapping after launch. Second, it saves time and money on development. Obsolete features can clutter a code base, causing confusion for new team members and making necessary features more bug-prone.

Conduct unit testing for continued functionality.

Implementing unit testing is another way startups can ensure the continued functionality of their product as they add new features and their user base grows. Developers can do this by building out a test suite before launch. That is, a package of automated tests to run before they deploy any new code. Having this checkpoint in place not only allows startups to avoid bugs and downtime in their app, but also to ensure the integrity of their code as they their engineering teams grow.

Unit testing is just one of many processes that startups can integrate into their engineering team’s workflow to ensure a scalable product. The Agile methodology provides a great backbone for helping engineering teams avoid roadblocks, respond to problems, and write better code. Holding weekly or daily standup meetings, for instance, helps each team member better understand and move forward with their responsibilities.

Recap on building a scalable product.

Building a scalable product, in a nutshell, means planning for the unknown. Apps don’t exists on islands — they’re part of the larger ecosystem of constantly updating browsers and devices. They connect with software that will continue to evolve and have users whose needs will shift over time. Startups can plan for this by creating products that are flexible enough to incorporate new features and swiftly adapt to technical changes and shifts in the marketplace.