Lean startup might look as an industry jargon for many, however, the process has flourished beyond Silicon Valley  and tops by Eric Ries’ viral release. The lean startup methodology gives companies (not only startups!) a framework to develop and launch new products. The method proposed by Eric Ries in 2011 states; devoting more time building services or products on a continual basis satisfies customers, clipping market risks and dodging the demand for huge amounts for projects and product launches.

To launch a new product (as an enterprise or a startup), you create a draft, pitch to investors, build a team with the right players and start with the marketing activities to hit the industry as hard as you can. Do you think every enterprise, mastering this timeworn action prosper? According to the study by Shikhar Gosh, senior lecturer, Harvard Business School, three fourth of the venture-backed firms fails. And the key to nail our enterprise in the market is the lean startup methodology.

Steve Blank, the serial-entrepreneur and mentor of lean startup movement, claims;

“No Business Plan Survives First Contact with Customers So Use a Business Model Canvas.”  goo.gl/uGc1Lo @sgblank @ekipa_co – CLICK TO TWEET

Hugo Messer, the global staffing specialist has come up with his experience on lean startup practices in combination with a remote (development) team.

The birth of Bridge, brainchild of Hugo took its first footsteps in 2005.  As time passed, the small startup grew, drawing positive ROI and established  its footprints in Ukraine and India. Bridge staffing now revamped as Bridge Global is moving successfully to its 10th year, cutting many odds. Ekipa, the global platform for software team is the next big leap and Hugo’s dream project connecting software teams around the globe.

A central part of lean startup is the business model canvas. At the start of Ekipa in 2014, Hugo and Piotrdutifully filled the canvas:Ekipa Canvas

Distributed Lean Startup – What Are The Challenges?

Ekipa.co was built by a remote software team in India from the start. Even the MVP was developed in India. Currently, Ekipa has a team of 3 marketers in India on top of the development team. A couple of challenges we experienced launching this new product with a remote team:

1. No programmer sitting beside you

The programmers are far away with a 3,5 to 4,5-hour time difference. As a consequence, you get:

  • Longer feedback loops

Ideally, your founding team has a programmer in it. When you get out of the building and speak to customers, you get back to the office and discuss the feedback with your programmer. He then implements the changes while you’re watching and the next day, you get back to the customer to show the changes. This is simply harder with a team far away.

  • Things can become slow

In general, you’re part of a process and this process can take longer with a remote development team. Working from different locations, requires more thinking about how you’ll collaborate and communicate. You need to develop a strong collaboration structure, implement the right routines and tools. Because you’re doing this while at the same time launching your new product, it might slow you down.

2. Routing feedback through the team

An important part of lean startup is generating feedback from users to build the right product. You need to go through the ‘build-measure-learn’ loop continuously. As Ekipa is a business to business online marketplace, it relies on personal interactions with customers. In a business to consumer site, it is easier to generate a lot of traffic on the short term (through AdWords). Business to business takes more time; less people are searching to ‘buy now’ and because deals are larger, nobody is interacting with your site right away (the process to get convinced that this is the service you need to buy takes time).

Therefore, our main instrument to learn is personal talks with prospective buyers. The points we took from this:

  • Team lacks direct talk with the users

Part of your team won’t have the direct interaction with the users. So the ‘onshore’ team (in our case, the 2 founders) talk to users and gather feedback. The information the remote team receives is therefore always ‘second hand’.

We have implemented Slack to route the feedback to the team. We actually communicate everything inside Slack. What we like about this tool is that you can add your whole team (or even external users) to the Slack domain. Then you can create open channels or private groups. In the private groups, you can assign certain users from your team with whom you want to share information. So for the feedback we receive from customers, we add reports to slack which can then (or later) be read by the remote team.ekipa slack

  • Product Owner in Netherlands > translates feedback to user stories

The spider in the web of routing feedback to the whole team is the product owner (in our case Piotr). He translates the feedback we receive from users into user stories. Those user stories are discussed with the development team, which enables them to fully understand what our users gave as feedback + what we need to build to serve them.

Distributed Lean Startup – What Are The Smart Solutions?

1. Development team

  • Scrum

From the moment we built our MVP, we used Scrum in our development. Some claim that scrum makes sense only in a larger team, but we found that it helps the process even if you’re 1 product owner onshore and 1-2 developers in India. The power in this case is the meeting rhythm and the sprint cycles. You schedule sprint planning, during which you discuss all user stories and user feedback received. The team then describes the functional and technical details of each user story. They discuss the ‘weight’ of each user story and commit to delivering x user stories in the upcoming sprint. They ‘run’ for 1-2 weeks (depending on the sprint duration you choose > we recommend 1 week for early stage products) and deliver the functionalities agreed upon. During the sprint, the onshore product owner talks to the remote team every day for 5-10 minutes.

In our case, we choose to plan user stories in each sprint for only 50-60% of the teams’ availability. The remaining 40-50% we use to implement quick changes. If we receive clear user feedback that tells us we need to change something, we want to do that right away. By creating slack in the schedule of the team, they can indeed drop their current work and build the change. Not what Scrum would recommend, but for a new product, it helps reduce frustration on the founding team.Scrum

To support the scrum planning, we use Jira. In this onlinescrum board, the product owner continuously works on the backlog of user stories, which also contain the feedback he gets from users. The team moves user stories through ‘in progress’, ‘testing’ and ‘done’, so the onshore product owner knows what’s going on.JIRA

One major concern for startup founders is to get new features online right away. If we have to wait for 1-2 weeks till the sprint is finished, we get frustrated. In our case, we chose to prefer ‘having a feature live’ over ‘having each feature bug free’. So if a developer completes a feature, she puts it on the live server straight away. Again, from an engineering perspective, not recommended, but for an early stage startup, it needs to be done. I prefer showing users what they want to see over waiting to have something ‘perfect’. Of course, the more mature your product gets, the better it is to move to a more staged approach with an acceptance cycle and test/deployment servers.

2. Marketing team

Our marketing team functions differently from our development team. Where we use Scrum for development, we use the Rockefeller Habits to structure the management work. I have written extensively about this tool in another post.

Rockfeller habits

Creating an MVP versus Building Too Much

In 2013, Hugo went to San Francisco to attend the lean startup conference. He wanted to learn as much as he could about how Silicon Valley startups launch succesfull products. And still, Ekipa stepped in some of the holes that lean startup tries to prevent: building too many features.

We built way too much : why?

One explanation is that we started from an engineering background, so we love creating products and software. Also, the product is a continuation of our existing services firm, so we assume we know the industry well enough and our product will succeed.

Some other reasons:

  • Marketplace : Get supply to create demand

Ekipa.co is an online marketplace, we have supply and demand. Our assumption was that we had to create at least some initial high quality supply (in our case profiles of software teams) to convince clients to work with us. So we had to build functionality to enable providers to create team profiles. We actually started out using a product ‘Instant Magazine‘ for this so we didn’t need to develop code. With those profiles, we got very positive feedback from users and we decided that we had to embed this into our system. So we started coding. Looking back, I actually think we could have gone without any profiles. We could have communicated to the market that we have the top 20 teams from all over the world and entice them to contact us to find out more. Or we could have created some fake profiles. But we didn’t, so we coded a lot.

  • B2B :Its about trust & long sales cycles

Our aim is to attract larger projects (as a ballpark, between 10.000 – 100.000 euros). We were inspired by Odesk in building Ekipa, a site that attracts 1 Billion in projects. But the average project on Odesk is between 800-1000 dollars, a different story. For our type of project, customers expect to talk to a person. This person should gain their trust, understand their needs and provide the right solution. This process takes time. Because this takes time, we didn’t get customers right after our launch. Right now, we’re continuously changing the site in order to create this trust faster and build the right business model.


The customer feedback

To learn what we need to build, we rely heavily on customer interviews.

  • No traffic, no data –> customer interviews

As described above, we’re in a slow moving market. We’re not able to attract large amounts of traffic on short term. Therefore, we have to go out and speak to prospective customers.

  • How to get the right questions?

One challenge we faced was ‘what questions to ask’. In an interview, you’re 2 people talking. Talks can move anywhere. As a founder, you don’t always know what to ask. As an interviewee you don’t always know what to reply and you’re mostly trying to be nice to this guy who risks his life to build this product. To get an impression of the questions we used, see our survey:

  • Huge tunnel vision

Another big challenge we faced was our 10 years of experience in the industry. Because Hugo has been thinking over the business model, the industry, the customers, the solutions, for a long time, his brain assumes it knows everything. If you’d start in a completely new field as a founder, you’re probably more open to any feedback.

This is the questionnaire we used at the beginning of this year to generate feedback:

  1. How do you take on / deliver projects if you don’t have the people available?
  2. If you consider hiring an external team for a project, how do/would you search?
  3. Have a look at a sample team profile
  •    On a scale of 1-10, which items are important for you to see in the profile of your team:

>the company
>the way they take a project from A to Z (process)
>team details
>profiles/cv’s of individual team members

  • What would you like to show about your own team? What did we miss? What would you remove?

4. What would be the decisive factor to make you work with an external team?
5. What would it take for you to post your first job on our platform?
6. How would you describe our platform in 1-2 sentences to someone else?
7. Who do you know that could benefit from using our platform?


Around 50 + people were interviewed.


When we started interviewing, we had the following expectations:

  • Cues on what to develop versus what not
  • Validation of the concept
  • Leads


  • Messy feedback, but we saw patterns

Some major things we learned from the feedback were:

> reviews; to create trust, users wants to see reviews from clients who worked with the teams. So not only our Ekipa vetting (our opinion), but open feedback from their customers.

> from individuals > teams; We made a pivot in 2014 based on the feedback we got. Initially, we had built a database of individual programmers, employed by a company. But from both sides we learned that this solution is not what the market is looking for. So we decided to pivot the system to ‘teams’ of people working in companies.

> sales versus post project; For projects of 800-1000 dollars, people simply post their requirements on a website and wait for bids. They’ll pick someone to build it since the risk isn’t big. But for large projects, they need to speak to someone. So our assumption that we could generate large requests through the site still holds, but we learned that we need to add sales to the equation. This lead us to build partnerships with people from all over the globe to represent Ekipa locally in their country + organize the delivery to the customers.

  • 95% ‘yes great platform’

For what it’s worth, almost everyone bought in to our concept.

  • Few leads

We had expected that a solid % of the interviewees would become interested in our services. It’s still too early to conclude whether we achieved success here, because of the longer sales cycle we’re part of. But we did get a couple of requests and started some initial projects, because we interviewed people directly in our target customer group.


  • Lean distributed development works

> Use Scrum

> Ideally, build your remote team after the MVP proves you’ve got a scalable business

  • Remote management

> Use the Rockefeller Habits

  • B2B: Qualitative interviews in structured format gives clarity + prospects