computer code showcasing product development risk reduction
Jul 11, 2018 Written by goji

Product Development Risk Reduction: A Guide for the Risk Averse, Part II

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.

product development risk reduction

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.

Get our newsletter

The Goji Berry is a monthly resource for startups, nonprofits, and corporate organizations; a compilation of all things product development and industry.

And no, it’s not like all the other newsletters. It’s a *cool* newsletter.

"*" indicates required fields