A healthy relationship with your outside development team begins with clear expectations. Both parties need a clear understanding of the format and scope of the arrangement. If you fail to set expectations at the beginning, there’s a chance one or both sides will disappoint the other. In worst cases, this could affect the development of the product, creating unnecessary cost and frustrating delays.
Image: dilbert.com
Fortunately, setting expectations is simple as long as you do it at the beginning of the relationship. In this article, we're going to give you advice to set expectations with your outside development team. Use this information to kick off a healthy relationship.
Meet in the Middle
Before you begin your relationship with an outside team, it’s important to understand that setting expectations is a conversation, not a monologue. Don’t be surprised if the team pushes back on some of your expectations and tries to set a different dynamic.
For instance, let’s say you ask to participate in every morning standup meeting. As the product owner, this would be unusual. Normally you wouldn’t be a part of the day-to-day engineering. In this case, the development team would probably resist and respectfully explain why that isn’t appropriate.
Similarly, you should expect the outside team to try to set the tone and pace of the relationship. They don’t do this because they distrust you or want to control the relationship, but because they typically have more experience in this type of relationship. They get hired by managers like yourself far more often than you hire outside teams. In many cases, it’s smart to heed their advice about how these relationships work.
That said, don’t be afraid to push back on something if you aren’t comfortable. Do you want more updates? Shorter delivery intervals? Better documentation? Communicate these concerns early so the team can agree to your expectations or explain why they can’t. But like we said, don’t expect the development team to immediately acquiesce.
User Needs and Business Goals
One of the first things you should do with an outsourced team is give them a foundational explanation of why you’re building the new application. This conversation typically hovers around user needs and business goals. Only once they truly understand these two perspectives, they will understand what a "win" looks like and can build a product that can achieve its goals.
(Technical constraints also play a role here, but it’s better to leave that challenge to your outside development team.)
Image: parliament.uk
Let’s say you’re building a sales SaaS designed to organize new leads and accounts. A product for a sales rep who sits at a desk all day might look very different from a product for someone who spends most of their time on the road. Your development team couldn’t possibly build an effective product if they didn’t know this pain point.
In some cases, the team may ask to speak directly to your user or customer so they can ask penetrating questions. These meetings can be invaluable for everyone, so try your hardest to make them happen.
Further, don’t be secretive about your business goals. Do you want to increase user usage? Increase order values? Automate work so you can downsize your staff? Break into a new vertical? The professionals on your development team understand that you have business expectations that need to be met, so communicate those needs so they can help.
By making user needs and business goals part of the conversation, you help the relationship focus on performance outcomes rather than shallow measurements. Ultimately, hitting both of these targets is more important than even cost and timelines (within reason, of course).
Mission Statement/Values
It’s helpful to lay out your expectations in a succinct mission statement and/or list of values. These help your outsourced development team understand what you hope to get out of the project.
For instance, let’s say you ask your developers to create a UI with minimal buttons and options. That’s a deliverable, not a value. A value would be something like “easy to use,” “fast to operate,” or “little decision-making necessary.”
A minimal UI is one way to meet that value, but there are probably more techniques your development team can utilize to make the app easy and fast. They might suggest a multi-step menu with limited options, features hidden based on permissions, etc.
Further, communicating values helps the development team meet your needs across the entire application, even in places you never thought that value could be met. They might meet your “easy to use” needs by adjusting button text, including tooltips, etc.
Mission statements and values are also useful beyond the project. For instance, if you intend to expand the application in the future to adhere to a broader roap map, it’s important that you explain this intention to the team. They may be able to build the product in a way to make adding future features easier and less expensive.
Let’s say you’re building an internal tool to help your employees access human resources functions. A mission statement might look like this:
Our mission is to create an application that reduces the burden on our HR team by empowering employees to access and change their compensation information and benefits without the assistance of an HR representative.
A list of values for this app could look like this:
Easy and fast to use
Expandable for future functions
Accessible on any device
Performs well under high load
Integratable with other platforms
Explains complex information
That said, don’t confuse values with deliverables. In many cases, you’ll need to spell out exactly what you want from the project. Let them know if you have unavoidable launch dates, hard deadlines, technology requirements, or must-have features that are nonnegotiable.
Expectations for Yourself
Finally, it’s important to set some expectations for yourself. That is, lay out what the outside development team can expect from you.
Clearly define the role you expect to play as the project owner. Naturally, you’ll “champion” the product within your organization, managing the team’s progress and contributing resources where necessary, but it’s important to define this role further. Will you play a critical part in planning the project’s roadmap, or will you be more hands-off? How will you contribute when the team needs help?
Most importantly, set an expectation to transfer as much knowledge to the outside development team as possible. Work to arm them with as much information as you can accumulate to help them make a better product.
Don’t set any expectations that you can’t live up to. Before you tell the team that you’re “available for questions 24/7,” ask yourself if that’s a standard you can really meet. It’s far better to set a lower standard you can meet all the time rather than a higher standard you fail to meet.
Key Takeaway
Your outside development team isn’t a commodity to exploit and discard. They are a resource that can help you meet your goals. By setting clear expectations at the beginning of your relationship, you create a strong foundation for a successful endeavour that culminates in a quality product that meets your needs. Use the advice we outlined above to ensure both parties understand what’s expected of them.
