In my tenure working with founders, I’ve had the opportunity to watch more than my fair share of development efforts using contracted resources. For the business-oriented founder who has a strong idea but not a technical co-founder or resource in their corner, it’s a viable way to get an MVP up and in the market to solicit feedback. But it’s not without its perils.

The first two parts of this series covered finding and contracting a development firm and have some great advice on how to identify a partner and structure an agreement that is mutually beneficial. I’d like to spend some time talking to you about what comes next, and the actions or mechanisms you can put in place to ensure success on time and within budget.

 

Check assumptions at the door

Sure, you might not be able to code in Python or understand React.js, but that does not mean that you don’t have a clear vision for your product. That said, does your vision always translate clearly to others, and do they understand the granularity of what goes into that vision? Ideally, this should be clearly outlined in your scope document, but you can’t assume that anyone other than the salesperson has read that document. By creating a product roadmap, clearly defined use cases, and user stories you can create a clear narrative around your product that is easily translated into development. If you don’t have that clearly defined, you are going to run into challenges because what’s in your head might not sync with the development team’s vision and is a sure bet to get you sideways fast.

 

Create a communication cadence

The best metaphor for building an MVP is like building a house. You have the design, the builder starts with the foundation, and development follows from there. Things come up during development that will require your sign-off or approval, and you’ll want to be involved to make sure that what is created matches what was scoped. This requires a frequent, productive communication process between you and the team building. The healthiest way to approach this is weekly (or more frequent) standups to talk about questions, progress, review capabilities, etc. It allows you to establish a shared understanding and language and ensures that there are no disconnects.

 

Manage changes, enhancement, and backlog via change orders

Sticking with the house metaphor, what you start within your design will have to change to accommodate some unplanned functional issue or constraint. To ensure that you understand the scope of changes, as well as any related impacts or costs, outline the changes and related assumptions and charges in a change order to the original scope of work.  That work can’t be executed until you sign off on and agree to all changes. This ensures that you are all in sync while being clear about increases in scope that could impact the cost.  I’ve watched too many founders not manage this tightly, end up 100% over budget and still not have a working MVP.

This leads us to the next point…

 

Don’t be complacent

It’s so easy to step back and say, ‘they’re the experts,’ and end up with something that you didn’t expect or want. Be an active participant in the development process, asking questions and challenge assumptions if you think they are incorrect. The development team is designing to your vision, but they do not have the ability to read your mind or may have misunderstood something you shared. By taking an active role in updates, you will be better suited to ensure that what’s being built is 100% what you need.

 

Sign off only after you’ve tested

Go back and read that out loud. Completion of milestones must require sign-off before the next phase of development and payment is approved. That includes testing on multiple systems by multiple people. This is critical. If you build on a flawed foundation, your house falls apart. Same concept here. If you allow development to go ahead, and pay without testing or sign off, you are going to be out a lot of money because you will most likely have to pay someone else to fix the mistakes. This could send you 200% or more over budget and crush your ability to get into market fast. Demand the time to test and sign off, you won’t regret it.

 

Take time to build a partnership

A development partner is an extension of your team. Taking the time to build a relationship that allows them to understand and participate in your vision is crucial. This not only covers the functional and technical aspects of your solution, it also spans the way you communicate, how you consume information, and vice versa. The sooner you can get to a meaningful give and take, the more successful the development partnership will be.

 

While hiring an outside shop to develop your product can feel like a scary prospect, you can learn to navigate it successfully by taking the time and creating structure around your effort.  If you’d like to talk to someone at JumpStart more about finding and managing development resources, please reach out.  We have years of knowledge on this and are always happy to help.

---