{"id":6101,"date":"2013-10-31T10:34:40","date_gmt":"2013-10-31T10:34:40","guid":{"rendered":"https:\/\/www.bridge-global.com\/blog\/blog\/\/?p=6101"},"modified":"2023-02-07T07:16:11","modified_gmt":"2023-02-07T07:16:11","slug":"lean-distributed-startups-how-to-launch-your-product-with-an-offshore-team","status":"publish","type":"post","link":"https:\/\/www.bridge-global.com\/blog\/lean-distributed-startups-how-to-launch-your-product-with-an-offshore-team\/","title":{"rendered":"Lean distributed startups: How to launch your product with an offshore team?"},"content":{"rendered":"

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<\/a>.<\/p>\n

The lean startup method<\/a> 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 <\/a>(I absolutely recommend it!).<\/p>\n

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.<\/p>\n

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).<\/p>\n

To develop this method, I have now tried several setups:<\/p>\n

    \n
  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.<\/li>\n
  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.<\/li>\n
  3. A programmer from India came with the idea. The product owner and scrum master and developer are one and are in India<\/li>\n
  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.<\/li>\n<\/ol>\n

    In model A, my findings are:<\/p>\n