Lean distributed startups: How to launch your product with an offshore team?

The past months, I have been experimenting with the lean startup method in a distributed setting. Let me explain this, because if you are not an offshoring insider, this could sound like gobbledygook.

The lean startup method you probably have heard about. The essence of the method is: if you have a (software/internet/app) product idea, develop a minimum viable product as fast as possible. This could be an 'alpha' version of your software, but even better is a 'simulation of your idea'. An example: you plan to sell cars through an app. The first thing you want to do is to test the assumptions you made, for example 'people are willing to buy cars through an app' (or 'people will download an app that promises them to buy a car'). To test this, you develop the most simple app imaginable (and you launch it on android because apple makes your life harder when your app is buggy). The app has one screen, shows one car and an 'order' button for example. You launch this and see if someone will download the app. As soon as you get your first order, you run to the closest dealer and drive that car to the person who ordered it. This will prove your hypothesis/assumption. Only then you start developing the 'real' app and in that you continuously test assumptions as opposed to 'building features'. To know more, it's best to read the book (I absolutely recommend it!).

The distributed part is people working on the product development from different countries. Typically, the developers are for example in India or Ukraine, while the person owning the product or marketing the product is in another country.

I am currently developing a bullet proof method to do as much of the work as possible offshore in our office in India. The goal is to develop our own internal products as well as service customers (Startups or existing software companies/department) through our lean distributed startup method. We always combine lean startup thinking with elements of scrum (which is our default software development methodology).

To develop this method, I have now tried several setups:

1. The person with the idea is in the Netherlands. He is the product owner (the person making all the decisions on what to develop and what's next). The scrum master and the development team are in India. The process manager is in the Netherlands (the person facilitating the communication between the product owner and the offshore team). This is an external idea which we incorporate in a joint startup.
2. An idea comes up in India in close interaction with myself (I am in the Netherlands). The product owner is in India, the scrum master and development team too. This is a 100% internal product.
3. A programmer from India came with the idea. The product owner and scrum master and developer are one and are in India
4. The product owner and the scrum master are in Germany. The development team is in Ukraine. This is for us the most typical setup in servicing our customers, where we serve as the development partner.

In model A, my findings are:

• The product owner is a non-technical person who hasn't got experience in developing software products, so the offshore team gets a lot of autonomy in developing the app from scratch. This spurs creativity and engages the development team
• The process manager can feel a lack of progress from both sides. As the product owner is an outsider (and the marketing depends on that person) and the team is remote, he is not fully 'in control' and has to remove many blocks to keep the team going.
• The product owner can feel a lack of progress, because he wants to get his product out and can't see on a daily basis what the developers are doing (entrepreneurs are typically impatient).
• Because the idea didn't originate from the development team nor our own company, the product is not completely their 'baby' (which I believe is an important ingredient for startup success).

In model B:

• Because it is an internal product, the development team takes full ownership of the product.
• Even the product owner is in India, which creates more dynamics in the team, they keep discussing ideas and are excited to see the first interactions with customers.
• Although it is hard to get this into a development team, the product owner and scrum master even start thinking in terms of marketing and create immediate product changes based on user feedback.
• The 'flip side' is that I am very keen on getting the app out, getting customer feedback, moving fast. Because the team is far away + I am not the product owner (so I am not allowed to interact on a daily basis), impatience plays a role on my side.

Model C:

• Here you have a technical team that came up with the idea and they are keen on getting the product out, which went very fast.
• But then marketing the app, generating feedback comes up and here the product gets stuck.
• Because nobody in Europe is involved, I sense there is nobody to 'fire up' the team and get going with the product.
• This experience might be bound to the specific product and we'd have to experiment more to reach any conclusions

Model D:

• The full ownership of the product is with one of our customers in Germany, so the whole product roadmap is devises in Germany.
• The scrum master planning the sprints and committing to user stories is together with the product owner; to get full involvement with the remote team, sprint planning is done using Skype.
• It helps to have another scrum master in Ukraine.
• The team typically focuses on technology, architecture, feature development and not on product roadmap, marketing, generating user feedback.

I will write future blog articles on this lean distributed startup methodology later on. The preliminary conclusions I made now:

1. For servicing customers as an offshore or nearshore provider, model D works best. One can vary with having the scrum master remotely, but the product owner should be onshore, close to the customer (although I can recommend the product owner to move to the team for the startup period!)
2. For our internal product development, having the full team, including the product owner, in India, produces the most engagement and progress. The team 'lives' the product.

I would be happy to hear about your experiences in remote startup development!