This post by Molly Hegarty originally appeared on the LookFar blog.
Winding up with the wrong technical partner is among the costlier binds that startup founders can encounter. So, why does it happen so often? One major issue we’ve noticed: not knowing the right questions to ask.
It’s happened to the best of us. Your prospective developer seems confident when you sit down to interview him, but when it comes time to execute actual work he just can’t deliver. Best case scenario, you’re able to cut ties with a limited financial loss. Worst case scenario, they drain your war chest and irrevocably damage your code. Unfortunately, many of our partners come to us after this type of interaction, feeling burnt out and understandably a little betrayed.
So we’ve created a handy dandy micro-interview for you to help vet any team you’re considering bringing on board. We’ll be giving you the tools you need to evaluate a technical partner’s ability to manage a product and work with you as a stakeholder.
Q: How will costs differ if I want to develop for iOS and Android simultaneously versus one over the other?
A: “Costs will be much higher”
If a person or team says otherwise, consider this a red flag. Even if they plan to use a product like PhoneGap or Xamarin to save development time, they aren’t a wizard. Different requirements of the product mean creation of additional assets, setting up additional code for which assets are pulled and served dependent on the device, and testing on a variety of products. If you’re budget-conscious, a good dev team will help you figure out whether iOS or Android is a better first-step towards capturing your target audience.
Q: Can you send examples of previous work? What parts of this project did you contribute to specifically?
A: “Sure, here’s a portfolio. I’ve worked on…”
We always recommend asking to see examples of previous work. Not only will this give you a good sense of a developer or a team’s technical capabilities, it will also show you their attention to detail and ability to see a project through to completion (consider half-finished projects a yellow flag). Make sure you ask what their specific role was on the project. They may be showing you work that was built collectively, that isn’t representative of their skillset. Even with larger, established companies, they may work with an external design firm, or partner with a hosting company. Make sure you know which aspects are handled internally and which will be outsourced.
If you’re looking to build an app, pay particular attention to any work they’ve actually published to either the Apple Store or Google Play. Published apps are apps you can personally test, and they also give you a chance to gauge the reaction of a larger audience of users to your partner’s work.
It’s also important to know how this company works. Even if you trust their development team, you need to feel confident that they will:
- correctly interpret your vision
- keep in close communication with you
- meet deadlines
- respect your budget
- move forward in a way that’s best for you, not the easiest for them
Q: How do you gather requirements?
A: “We have a specific process, here’s how it goes”
If a team says “we’ll talk it over” or “we have a brief meeting,” consider that a red flag. Requirements gathering should be done formally, with the results documented. Requirements can be gathered in the beginning or throughout the project, just make sure there’s an established process for gathering requirements and documenting changes over time. At the beginning of a project, the team will likely produce wireframes or workflows, which should then be thoroughly discussed and reviewed by you before they write a lick of code. Requirements gathering should also be ongoing, with the current state of the project assessed and reviewed, as requirements always change throughout the development lifecycle.
Q: What happens if I change my mind about a feature or design?
A: “We expect changes will occur and have that built into our budget and timeline”
There is only one certainty in software development, or any large project, really: requirements will change. Any experienced team will understand this and have a process in place for dealing with this inevitability. Ask for more details about how they’ve handled clients in the past who have had major design or scope changes mid-project.
Q: How does your team handle project management?
A: “We’ll have a designated employee act as project manager”
Project management must be a priority with a designated person for communication. Since you’re not an expert, the communication about timeline, requirements, scheduling, product design and other details is crucial. You’ll be learning throughout the process of developing your idea into a product. Good project management will make that process easier and faster. The last thing you need is to be frustrated with confusion over incomplete requirements gathering, vague time estimates or surprises like ‘That feature? You never said you wanted that done.’
General aspects of project management can include:
- Communication
- Scheduling & timelines
- Requirements management
- Change management
- Recording key design decisions
- Maintaining the budget and scope of the project
A good rule of thumb is that a typical Project Manager handles 2-4 projects simultaneously, depending on the size. If your project is large and will be requiring more than 2 full-time developers to complete it, your PM should really be exclusive to your project, or at most, handling one other client.
We hope these questions will help you make an informed and confident decision when choosing a tech partner. Whether it’s us or somebody else, you deserve a development team who can do what they say they can do!