At SmartLogic, we work with a range of clients. Some have spent months thinking through their products. On the other extreme we get inquiries from people that have an idea and have never engaged a development firm before. Then there are companies firing a development vendor and seeking a more competent team.
This article is part 1 in a 5-part series explaining some best practices for how to approach the process of hiring a development team for your product development.
Let's assume you've decided you're outsourcing software development. It's critical to get this decision right because you will be spending a significant amount of time and money with said team. Much like marriage, you should court a few vendors before committing to a long-term relationship with any one vendor.
The process I recommend is as follows:
- Get organized: prepare a document you can send to each vendor you’ll interview. We’ll provide more details on this below.
- Find potential suitors: you’ll want to talk to 3 or more prospective development partners.
- Interview them: have one or more conversations with each company. Let your gut help inform your decisions. Watch out for red flags.
- Get proposals: proposals should at a minimum include: an estimated cost for a specified amount of work an explanation of the firm’s process; and other pertinent information associated with what you can expect when working with the development firm.
- Sign a deal: pick a winner and get moving; time is of the essence!
In future posts, I will cover each step of the process in detail. In this post, I will cover the first step: getting organized.
Get Organized with a Development Prospectus
To save yourself time, and help organize your own thoughts, consider putting together a document to share with the vendors you will interview. Note: this should NOT be an old-school voluminous RFP or RFQ; those are outdated modes of communicating what you're trying to build. Prepare a short document that at a minimum covers the following:
- An overview of what your product is trying to achieve, or at the very minimum, a bulleted list of features you want to build (this does NOT need to be an exhaustive list).
- Key team members and contractors along with their respective areas of responsibility.
- What you've accomplished to-date (wireframes? prototype? secured financing?).
- Timeline and important dates to consider.
- Criteria you'll use to make your decision. Is money less important than timing and quality? If so, then make that clear.
If you don't have all of this documented, expect any competent vendor to extract this information from you over the course of your initial meetings.
Good things to prepare:
- A development prospectus as outlined in this article.
- A small prototype or some wireframes. Just keep in mind that when Boeing builds a 747 prototype that prototype doesn't make its way to Southwest's fleet.
- A product roadmap, which will inform features to be built down the road. Keep in mind the roadmap may change; be flexible.
Caution Against Prepping Too Much Before Development
While you clearly need to think through your product and have a good idea of what you're trying to build, it's often counterproductive to define features that will be built months down the line. The only thing that is constant is change; the features you want built into your product will change.
You might be going overboard if you have:
- Fully-fleshed out wireframes and corresponding designs.
- Complicated Photoshop mockups mapping out most functionality and screens in the application.
- Lengthy requirements documents, including "functional specifications" and other similarly detailed documents.
A Caution Against Wanting to Start Yesterday
Not to say that time isn't of the essence, but if you don't take the time to set the stage for a healthy partnership, you will lose a lot of time down the road, and may even need to go through the messy process of starting again with a new vendor for your app development.