It’s no secret that along with major benefits like lower costs and access to top-notch talent, outsourcing comes with several risks:

  • deviations from your vision;
  • unforeseen expenses;
  • loss of control;
  • information leaks, etc.

The good news is that there are proven ways to mitigate these risks. Most of them require you, as a client, to get involved in the project.

Choosing a hands-off approach to development can often result in a disaster.

Several years ago we started the most dreadful project in the company’s history. We were to develop an e-commerce portal for hardwood floor manufacturers. The project was going as usual when our contact in the client’s company quit his job.

In his absence, the client started ignoring our emails and calls.

Developers managed to complete the project on time but the client wasn’t satisfied with the final design. The result was so different from what they imagined in their heads that we had to redo the whole thing from scratch.

As a result, the client wasted lots of time and money for no good reason.

They could’ve avoided all negative consequences by getting involved in development process

That’s why, from the very beginning, we advise to appoint a person from the client’s side that will be responsible for communication with the team and maximizing the product value. This person is called a Product Owner and he/she is one of the most important factors for the project success.

But how much time should a Product Owner devote to the development process? What if their schedule is already packed to the brim?

Here’s our quick guide to working with IT outsourcing companies.

Read more: what to consider before you start cooperation with an outsourcing service provider.

Agile glossary

Have a look at Agile terminology before you proceed to tips

1. Define your requirements

Time required: 16 hours (2-day workshop).

People involved: development team, Scrum Master, Product Owner, key stakeholders (e.g. senior management, sales representative, CTO/IT person, etc.).

From the very beginning, it’s important to set clear and formal expectations about the result you desire.

Vague requirements may lead to a product that doesn’t meet your business needs or disappoints your customers.

That’s why we encourage the clients who don’t yet have clear requirements to take part in a requirements gathering workshop. During this 2-day exercise, the development team meets the main stakeholders to discuss the essence of the future product.

Your first task is to define its target audience.

We do this with user personas (fictional representations of your intended customers). Crafting a different persona for each category of users will put a human face on your target audience and help you see the problem from their perspective.

You can use one of user persona templates that typically include:

  • User’s name;
  • Background and demographics (age, gender, family status, location, etc.);
  • Job position;
  • Income level;
  • Personality;
  • Goals and values;
  • Trusted sources for information; and
  • Pain points.

Put this information on a whiteboard and take a picture for later use.

client involvement user persona

Online book store persona: source:

Now, when you better understand your target audience, it’s time for feature brainstorming. Give all participants a bunch of sticky notes and 5 minutes to answer the following questions:

– What do you think is the goal of our product?

– What will motivate users to take actions in your app?

– What features do you think we should include in the first iteration?

When the time is up, each person will read their answers aloud and put them on the whiteboard. Different participants will often bring unique perspectives and you’ll be surprised by how different their answers could be.

After everybody presents their answers, it’s time to vote for the best features to include in your backlog.

And if participants get tired, you can spice things up with some fun games.

For example, when brainstorming ideas for a home decor store, we asked the participants to write a story about their dream house, one word at a time. Keeping the story coherent when each participant can only write a single word is an excellent workout for creativity.

After you define all the large chunks of functionality (called epics), you’ll have to break them into smaller features and prioritize them for your first sprint.

This is a long and tiresome activity, so you can mix the routine with some creative tasks.

For example, you can ask the participants to draw the perfect design of your app (and be surprised at the differences in their vision). Or you can ask them to imagine the product’s success. Not only does it engage the participants’ creativity, the exercise can also help you identify goals and KPIs for your product like:

  • The number of visitors per month;
  • The number of purchases per day;
  • The average number of items purchased per user, etc.

Correctly defined goals and KPIs will allow you to monitor the success of your product. If some KPIs start falling behind target, you can investigate the reasons and fix your app.

Remember to keep your goals S.M.A.R.T. – Specific, Measurable, Achievable, Relevant, and Timely.

Further reading: how to avoid 5 deadliest pitfalls in requirements gathering process?

2. Get involved during the discovery phase

Time required: full-time.

People involved: Product Owner, Tech Lead, Scrum Master, development team.

Discovery phase (sprint 0) is the first stage of development that allows the software contractor to analyze your requirements and create a specification for your system.

During this time, you’ll get to know your team, figure out your target audience, and create a list of features to be developed in the next sprints.

Developers will configure their environments and make all necessary preparations to start working on sprint 1 without any distractions.

For large companies, it’s essential to have somebody on your side with technical expertise (e.g. a CTO or IT person) to oversee the design process and ensure the team selects technologies that fit your business objectives.

3. Plan like a team

Time required: 4-8 hours for a 1-month sprint.

People involved: Product Owner, development team, Scrum Master.

Before the start of an iteration, you’ll need to run a meeting to set the sprint goals and discuss the amount of work to be done. The Product Owner would prioritize the items on the backlog while the team estimates the user stories.

4. Take part in meetings

Time required: 1 hour per week.

People involved: Product Owner, Scrum Master.

Each week, a Scrum Master would contact the Product Owner to discuss the progress made on the project. During these meetings, we usually discuss design updates, review feedback from users and stakeholders, and check our KPIs.

5. Monitor progress made by the team

Time required: up to 10 hours/week.

People involved: Product Owner, major stakeholders.

During the sprint, the Product Owner’s role will be limited to participating in status meetings, discussing design with stakeholders, updating the backlog, monitoring progress towards sprint goals, clarifying user stories and answering the team’s questions.

6. Review the sprint results

Time required: 1-4 hours per sprint.

People involved: Scrum Master, QA engineer, Product Owner, major stakeholders.

At the end of each sprint, the team will review the progress made on the project.

Typically, the Scrum Master or a QA engineer will travel to the client’s site and give a live demo to major stakeholders. They would go through the completed features, point out existing bugs, and answer stakeholders’ questions.

During the presentation, a Product Owner will have an opportunity to review the sprint goals and update the product roadmap.

As a result of the demo, you can either approve the sprint for release or reject the iteration.

7. Keep in touch after the release

Time required: minimal.

People involved: Product Owner, support team.

Once you implement all features, the project can transition to the support phase. The team will stop active development and move to other projects.

You can, however, still request the outsourcing IT company to fix any issues with your product.

Wrapping Up

I hope this cleared some of your questions about working with IT services companies.

The takeaway is that you’ll have to devote some of your precious time to ensure the resulting product matches your vision.

On average, you’ll need to spend ~10 hours/week working on the project, reviewing the backlog, and communicating with stakeholders.

From our experience, highly-involved clients have a much higher level of satisfaction and can fully realize their product goals.

Now, If you want to know more about working with IT outsourcing firms or need a team of experienced developers, don’t hesitate to contact MindK and schedule a free consultation.

e-book agile development