Guidelines for setting up a strong relationship between the executive team and the product development team.
Free Book Preview: Coach ’Em Way Up
Discover how to be an influential mentor through tips and advice based on the teachings of respected basketball coach John Wooden.
December 9, 2020 7 min read
Opinions expressed by Entrepreneur contributors are their own.
Whether you’re building an app for your startup, a marketing website or an advanced enterprise digital workflow system, the guidelines for setting up a strong relationship between your executive team and your product development team are the same.
Software projects have a reputation for being expensive, taking too much time and devouring capital and resources before actually launching and proving themselves. Over my company’s ten years in business as a product development team, we’ve seen successful structures and learned a lot of best practices for how to manage the process along the way.
At the core of the product development team relationship is good communication. We have found it extremely vital to make sure that executive stakeholders and the development team are aligned and understand the needs and limitations on both sides of the equation. Everybody needs to be very clear on what exactly is going to be delivered.
As an executive leading a software development team, the most important thing to remember is that it’s not you on one side and the developers on another, it truly needs to be a collaborative effort. Good software leaders provide direction, gain alignment and actively surface problems through the proper use of a few important management tools.
Over the years, my company has developed a plethora of systems and tools that help us collaborate effectively with our client stakeholders. As we’ve been asked to do more consulting rather than just development work, we’ve found they work universally for all kinds of executive development team relationships. Here are the guiding principles of those systems and tools as action items:
Before beginning the process, make sure you understand:
Your budget for your MVP (minimum viable product.) This is the first iteration of your product that you will get into the hands of testers, so you don’t need to blow the bank on this first round. You just need a product that delivers the core value, just enough features to attract customers and validate your product’s usefulness to those customers. This doesn’t have to be the most perfect version and can be easily deployed in a closed beta.
It’s important to understand that, whether internal or outsourced, you’re paying your product development team for their time and the more features, integrations, APIs, etc., the more costly the project will be.
Depending on complexity, we typically encourage most clients to target a MVP cost anywhere from $50,000 to $300,000. In almost all cases, this should provide you with the first working version of your product. So if an external product development team is charging you outside of that range, or you are budgeting upwards of $500,000 for your MVP, closely examine why that is and whether or not it’s truly necessary to spend that just to deliver the core essentials.
Your timeline. Make sure you know when you need the product ready. Having a realistic timeline goal is important to keep everybody accountable. If you need a finished product in a month, very few product development teams are going to be able to produce something successful in that timeframe, unless it’s a very simple website. Remember, you want to first get a MVP into test users hands first. Determine when you want that to be. From there, you can develop key milestones you want to meet before then and key milestones you want to meet after that.
When interviewing developers, whether an external team or in-house, make sure you:
Ask for references. Yes, seeing client work and reviews on a website are important, but remember, any developer you are hiring is only going to share the best of the best when it comes to completed work and reviews.
Ask this prospective developer for references — plural. Plan to have a thorough conversation with those references. Ask about the entire development process, because you want to find people who can start from a concept and build something polished and scalable. There are several different skills involved throughout the lifecycle of an early stage product, so you’ll want someone who can handle the ambiguity of early concepts and the attention to detail that is required of a high quality product. Of course a great question to ask is always “Would you hire them again?” Listen carefully to how they answer this question, and you can usually tell in their tone if something is off.
Ask about their agile process. Developers and definitely development teams (if you’re hiring externally) should have a well established agile process they have utilized with successful results before. Make sure they can give you a comprehensive rundown of that process.
Furthermore, ask about how well they adhere to that process. Often, you’ll hear developers and product development teams talk a lot about their agile process on their website, in interviews or in published thought leadership pieces, but how well they stick to that process is a whole other ball game.
Ask questions in the interview process like, “How did you handle and adapt to changing requirements on a previous project?” They should be able to then walk you through their process. If this example is from one of their references, that is even better.
Ask them about how they work with design. User experience will instantly make or break the success of your product, so design needs to be an extremely important part of the process. Any good developer knows this.
If you are hiring a product development team, make sure you understand the individuals who will be responsible for design and that both designers and developers have experience working with each other. One of the biggest reasons software projects fail is because design and development are not aligned.
Once you’ve hired a product development team, make sure you and the team both:
Understand the vision. This seems obvious but might actually be the most challenging thing to communicate. It is very easy to picture your dreams in your head, but to communicate them to a team to develop is a whole other challenge. That’s why having a well-written vision brief is a great tool to start out your product development project. We tend to give our clients our vision brief worksheet as homework before project kickoff. That worksheet includes questions like:
- What are the goals of this product?
- Who’s going to use it? Who is the ideal target audience?
- What features are a must-have and what are nice-to-have features?
- What are the top priorities of the product?
- A vision brief document acts as a project’s blueprint. It can evolve over the course of that project, but it’s a great starting point. From there, both you and the product dev team can review the brief together, ask questions, edit and add as necessary. Once finalized, make sure this document is shared with everyone on the project so everyone is on the same page and regularly review it to ensure alignment
There are so many good product developers and development teams out there. Whether you’re hiring internally or externally, I’m sure you’ll be able to find the right fit, but remember, you can’t be too thorough throughout the hiring process. It can be very difficult to switch teams mid product development.
And, most importantly, while building a product is hard work, you should have a good time doing it! Positive collaborative energy is the primary driver of good results so make sure you’re working with people you like.