A guide to product development for the risk averse, Part 2


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 avoid them. 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 drew up 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.