Working with a remote team: How to be a Rock Star Product Owner

3 min readAug 14, 2017

You could see many articles written by outsourcing companies about irreplaceable and very important Product Owner’s (PO) role during the software development process. In fact, the more engagement, the better, faster and high-quality product will be developed.

In real life POs usually have already running own businesses, and give main priority and time to it.

The outsourcing development statistics shows that less than 20% of projects with remote developers are completed successfully. And less than 20% of startups survive after first year of working (source http://www.go-globe.com/blog/startups/).

Can one blame a PO that he/she spends only two hours a week to his new project? Should an offshore team be blamed that they critically depend on the PO’s engagement and can’t work without his/her active participation?

Here is what gives any project better chances to succeed and allows a PO to minimise his/her engagement.

Tools to automate communication:

Record video for the PO once per 1–2 weeks.
The spreadsheet with a list of questions to the PO.
Jira/Redmine/Basecamp/Trello — collaboration software.
Continuous Integration approach.
Dynamic CI — automated code promotion.
Git/Github flow — Separate environments for Dev, Test, Production.

Such automated approach allows to draw the PO in conversation and give feedback about a new product version once in 1–2 weeks. At the same time, the methodology in development is not so important, whether it can be Scrum, Kanban, or Waterfall.

Team expertise:

A team with a good expertise in a specific business domain, or that has already been doing a similar project, makes fewer mistakes and spends less time fixing errors respectively.

Let’s say you need an e-commerce.

Team A — without expertise. 50% of change requests based on PO’s feedback.

Team B — with less expertise. 30% of changes.

The team C — has been building only e-commerces for 10 years. 10% of bug fixing.

Planned scope — 400 hours in the ideal world.

TeamDelivery time GrowthDelivery time ResultTeam A400+50%600 hoursTeam B400+30%520 hoursTeam C400+10%440 hours

Price:

A price shouldn’t be a decisive factor for choosing a subcontract. If you take a specific region you want to employ the outsourcing company in, then a price of various companies may differ insignificantly no matter the size of the company.

For example, in Eastern Europe (Ukraine, Belarus, Bulgaria, Romania, Moldova, Poland, Hungary, the Czech Republic, Lithuania, Latvia, Estonia) 3+ year-old companies with a good portfolio have an approximately equal hourly rate. There are exceptions, of course, but they can have shortcomings as bad English, a large-scale team distribution, inability to provide turnkey service (example: no UX/UI, no DevOps, etc.).

Transparent work environment:

During the development process, a team has to show the change related statistics.

Such metrics as:

Planned features,
Change requests,
New features

have to be highlighted by the team, have to be estimated and available for the PO’s reviewal and prioritisation.

Example:

Planned ScopeUnplanned ScopePlanned FeaturesEstimateChange RequestsEstimateNew FeaturesEstimateFeature 110hChange to Feature 15hFeature 2310hFeature 220hChange to Feature 33hFeature 2415hFeature 310h — Feature 255hFeature 430h — Feature 267hSUM70hSUM8hSUM37h

In conclusion, here is a check list:

Choosing a team, use two core criteria: similar projects in the portfolio and the total number of released projects. Evaluate projects: how successful they are today, and whether they are working today or not.
Check references from the former clients. Do not hesitate to contact a client of any project through LinkedIn, Facebook, Angel.co, and ask him a couple of questions.
Use basic development flow automation software: Jira/Redmine/Basecamp/Trello, Git, Google Spreadsheet.
Ask to make a project roadmap and milestones before kicking off the development, and accept each milestone mentioning the result as fixed.

Good Luck.