computer code showcasing product development risk reduction

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

David Barlev

July 11, 2018 · 2 minutes

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.

About David Barlev

David is the Co-founder and CEO of Goji Labs. David loves working closely with passionate founders to understand their vision and help them build beautiful applications while focusing on risk-mitigation. As an author, he focuses on informative and educational blogs that enable our clients to make the most of their businesses.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Up next

October 14, 2021

Let’s talk features of successful EdTech apps —because even if we don’t count the obnoxious…


October 12, 2021

When designing your site, it’s essential to know what’s up—industry-wise—and keep track of prevailing B2B…


October 6, 2021

Continued from our Part I: How to Choose Your B2B Go-to-Market Strategy 1. Objectives First…

ProductBusiness TipsStrategy