Most startup founders have either heard of (or experienced) difficult, sometimes unbearable, relationships with developers. I was no different. During my first startup, I too experienced my fair share of ups and downs in the client/developer cycle while building our product. As time progressed, and as I began working as a developer myself, it wasn’t long before I realized that doing some simple things would have saved A LOT of time, money, and headaches towards past developers. Below are six ways founders can build a successful relationship with their development partners.
image credit: https://www.flickr.com/photos/sybrenstuvel/2468506922
Start a successful client / developer relationship with these 6 tips:
1. Tell your (brief) story
Do
Share your business / project in 3 – 4 minutes. Developers are not investors (most of the time) so don’t give them a slick presentation with no sense of reality. Tell them about you, how you came up with the idea, the key problem and solution, and who you are solving the problem for (your customer). We recommend using Lean Canvas or Business Model Canvas as your guide for what’s important to talk share and what will get the ball rolling.
Don't
Share your life story about how you and your business partners are BFF’s and come up with like 100 ideas a week. That’s great and all, just not necessary. You are there to build your one idea, and build it well. Stay focused. Don’t go on tangents every chance you get (even if the people in the room seem interested). Remember you need to build a product first, you can shoot the shit after the product launches.
2. Walk through how your target customer would use the product
Do
Define who your target customer is. What does he / she do for a living? How old is he/she? What does he/she do on a Saturday? Where would they hear about your product / business? When during the day would they use your product? Walk your developers through 1 to 2 well-defined use cases from when the customer heard about the product, their first experience with the product, and what makes them continue to use it.
Don't
Say your product is for everyone. No product is for everyone and if it is, I hate to break it you but it’s not going to work. Define who your ideal person is and how they use your product. Which of your friends would use it? Don’t define characteristics about your ideal customer that aren’t relevant to your product. For example, if you are selling a food product, the person’s hair and eye color probably aren’t that important to you (at least not as much as if they were lactose intolerant). If you had a beauty product, hair and eye color would play a factor.
3. Show and discuss the key functionality (but not every detail of every page)
Do
Bring Sketches. Bring Wireframes. Bring an inspiration board (or share one on Pinterest). Bring your idea of the main functionality and show it to developers BEFORE you start a project. You should have a DISCUSSION about the key functionality (maybe 3 pages worth) and take things slow with your developer. Have them talk through things. This is their first time hearing / seeing your product that you have probably thought about thousands of times. Give them a little time to catch up. Trust me, they’ll need it. Last but not least, DO think through interactions (if a user clicked this, what happens. If a user does this, then what happens). This tells us whether or not you’ve done your homework in thoroughly thinking through the product and is often an important step that is forgotten about.
Don't
Bring / send a 30-page specifications document expecting everyone on the team to have read / understood it. Developers are humans, and can only retain so much information. It is better to level the playing field by talking though the first two weeks of work rather than the entire project. Besides who wants to read a 30 page doc?
4. Bring Sample Data
Do
Bring sample data that your developers can use. If you are going to sell products, have a folder with pictures and descriptions of the products. Maybe you have users? Instead create fake user accounts and some descriptions about who those users are.
Don't
Have your developers create this data (even if it is easier for you). It is too expensive for you to have developers spend their time creating this information. Your demo’s will look 1,000% better if you have representative data and pictures.
5. Discuss budget and timeline
Do
Discuss how much you would like to spend on the initial project. This doesn’t mean you need to share the total money you have access to, but discuss what you would like to target and have a discussion whether that is feasible or not with your developers. DO keep roughly 25 – 30% of your budget reserved for completing the project beyond what developers will estimate. Most projects make changes throughout the project and those changes have a huge impact on the overall budget. Go in knowing this information, and plan accordingly. Think Property Brothers from HGTV. You never go into building a new house without some tweaks, issues, or adjustments. Do talk through any critical deadlines you have for getting the product complete (like a major industry conference or tradeshow, major investor meetings, key seasons for your users).
Don't
Think that everything you say while discussion budget and timeline is a negotiation. Products take time to build and if you are withholding information, the only person it’s going to hurt in the end is you. Don’t make up false deadlines thinking it will make the project get done faster. You can get the project done on time by following #6.
6. Setup “demo day” reviews and a communication plan
Do
Setup weekly or at most bi-weekly reviews of progress. Take these meetings seriously and ask tough questions. Call out if something was supposed to be done and find out why it wasn’t and the plan to get it complete. Get an update of costs and compare that to the total scope. Are you on track? Do setup communication lines between you and your developers. We use a project management software like trello all the time for this process (email is really really bad for development). Setup how often you’ll chat (we will sometimes have a daily standup meeting with clients) and hold up your end of the communication bargain.
Don't
Miss key design and demo reviews. These reviews are crucial to getting the end product you want and will let you know where you stand financially. During these meetings don’t talk about future features or enhancements to the product, stay critical about what is built. Don’t setup “update” meetings for you to share how things are going on your end. Keep the focus on the development of the product.
Summary
As someone who has been on the other side working as a founder, I have seen and experienced my share of development relationships gone south. If I had a guide I can only hope that I would have managed those relationships in a much better way. If you have a great idea or want some help navigating the development waters, feel free to reach out to me at colin@differential.com
