Homepage / Insights / How We Built A Lean Startup Inside A 200 Person Company

How We Built A Lean Startup Inside A 200 Person Company

Creating a new product from scratch is never easy, but provides plenty of learning opportunities along the way.

Portrait for Envato By Envato
Posted 21 Oct 2013
How we built a lean startup inside a 200-person company

Lean is all about fast, validated learning. It’s a simple but powerful ideology for building a business. But a diagram and trendy name is all very well, how exactly do you put it to use in reality? And how do you do it inside an established business?

Late in 2012 I was tasked with building Envato’s next big product, Microlancer. Inside an existing company of some two hundred staff, I needed to assemble a small team, and create a business that is meaningful to a company of Envato’s size. With just six months to do it, I decided immediately that Lean would give us the best chance of success. We would build, measure and learn. But just as importantly, we’d constantly challenge our thinking, and be ready to change, pivot and adapt when needed. And we’d keep doing it until we found product-market fit.

Six months later we had a live product making sales, and six months after that we’re at a million-dollar run-rate revenue and growing fast. This is how we did it.

Microlancer lean philosophy

1. The Brief

Envato’s mission is to help people learn and earn online.

My brief was to create a marketplace for freelancers to sell their services to a large online audience. This would be a natural complement to our biggest product, ThemeForest, a marketplace for web templates and WordPress themes.

We had a great domain name – Microlancer.com – and a sketch idea from our founder and CEO Collis Ta’eed: “A prepackaged and priced freelance services marketplace”. In other words, a marketplace like ThemeForest, where instead of browsing files you are browsing jobs people could do for you. How exactly that would all work was up to us to figure out.

Collis and I put together a team consisting of four developers, a designer, a comms specialist, a product manager and myself. As soon as the team was formed, the discovery phase would begin in earnest. We needed to quickly find a product fit for actual customer needs, choose a niche, figure out what the service would look like, how it would work, and where our pain points would be.

2. Getting An MVP Up In 2 Weeks

To build something quickly, you need to think about small, quick and easy ways to test out ideas. One of the most powerful concepts in Lean is the Minimum Viable Product (or MVP). This is a kind of prototype product with just enough features to gather the learnings you need for your product development process.

The key to building an MVP is to figure out what you want to learn, and then how you can achieve that in the most efficient way possible. You need to be ruthless with every piece of work – assessing whether you really need it, whether there’s a shortcut, or a substitute, or just some other way you can get the learning faster.

For Microlancer, the things we wanted to know with our MVP were:

  • Is anyone interested in buying freelance work in a ‘services’ model?
  • What kind of pricing should we use?
  • What do typical freelancers, jobs and clients look like?

These three key questions would tell us if the service was viable, how to price it to be attractive and hopefully profitable, and how to add value for both the freelancer and client.

Our challenge was to build something to answer these questions. We quickly started listing out what felt essential to test our ideas:

In: A site where a buyer could choose from a selection of freelance services of different types and price points. A payment system so we could have real transactions. A way to communicate with a freelancer to carry out the service.

Out: Anything to do with signing up real freelancers (we’d use our own staff to simulate). Anything to do with dispute resolution (we’d just refund anyone who asked). Any sort of marketplace-like functionality (without real freelancers, we could ignore it all for now).

Our first big breakthrough in this process was to decide to simulate the freelancers with our own staff. You see marketplaces are tough to build because they rely on a dynamic of sellers and buyers. It’s a chicken-and-egg problem. It would take too long to recruit real freelance providers for our experiment. But we had some very talented people who could take on the work. This would let us observe the process in detail, get a feel for what it was actually like to do the jobs, and how cost effective it was for our ‘freelancers’.

We decided at this point to focus on graphic design services, and ask our two valiant Envato designers to take on the jobs.

It was effectively a simplified hyper-learning phase for the team.

We also wanted to go incognito since this was a brand new Envato product idea, in the earliest stages. When you’re making a new product in an existing brand network, you have less shelter for mistakes, more interest in what it might mean for existing products, and of course more competitor interest.

So, with the design focus, we grabbed a cheap domain name ‘Graphiclancer.org’ and made sure there was no public affiliation to Envato. This would make it harder to get traffic, but we’d be anonymous.

Testing a Microlancer MVP
Testing a Microlancer MVP

Now we needed to find a way for buyers to send a brief and for us to deliver the job. Building an entire messaging system for an MVP would slow us right down. As a quick substitute, we decided to use a customer support app to handle the messaging. This was made possible by our decision to have staff pose as the freelance service providers.

We used ZenDesk, an affordable SaaS app, for handling seamless email support, which has a good set of APIs for building on. Every time somebody bought a service we got a support ticket with a brief. Easy.

While our team of eight was modest by Envato standards, it was a pretty good size for a new business. Certainly a lot bigger than many startups! With a team this big, a small front-facing site was not a huge task and we immediately set to work on a few basic service pages, plugged in Paypal and Zendesk, and let Graphiclancer out into the wild.

Because we were a brand new team we needed to build trust with each other quickly and used the MVP project to fast track our bonding. There’s nothing like working on a shared objective, with a clear deliverable and short runway to bring a group together!

In two weeks we had a working prototype up at Graphiclancer.org with a set of design services that our two designers Rod and Jacob had offered up. We had each designer estimate the hours to complete a job, and then priced that at $25 p/hr. Our rationale: it seemed a likely median hourly rate when looking globally and online. It’s much lower than an experienced designer in the US might charge, but higher than what a less experienced designer in another part of the world might. It seemed like a good place to start our experiment.

3. Learning From The MVP

For the MVP we were interested in how many visitors converted to buyers, how many people registered their interest to ‘sell’ services with us (which was just a Mailchimp email signup form), how many jobs went to completion, and what kinds of services people were interested in buying. In other words, we poured over analytics!

We bought traffic through Adwords, placed some banner ads on our other Envato sites, and later created a small integration point with one of our marketplaces where buyers of logo templates got a link to ‘Customize my logo’ which sent you to Graphiclancer.

Three Weeks of Testing

Over three weeks in October 2012 we chalked up:

Sales: $360

Jobs Completed: 8

Interested Freelancers: 44

They were modest numbers, but full of learnings. Here’s what we learned against our three questions:

  • Is anyone interested in buying freelance work in a ‘services’ model? Yes (thank goodness!) It turned out there was a lot of interest from freelancers. And with a bit of marketing effort there was interest from buyers too that did indeed convert into paying customers.
  • What kind of pricing should we use? We had really mixed results even with our limited test. It spoke to the need to have a ‘freelancer chooses’ pricing system to cope with different styles, services and speeds.
  • What do typical freelance jobs and clients look like? Jobs took longer than we’d imagined and without strict rules in place about changes, buyers would ask for all kinds of alterations, even do odd things like disappear without ‘accepting’ the job’s completion.

These learnings were priceless, especially against a total of five weeks invested. Attracting buyers to Microlancer became the primary focus, while our freelancer focus would be on supporting the best to rise to the top. We also used our observations of jobs purchased and completed on Graphiclancer and used them to create the guidelines we give freelancers about how to structure their job ads, and our dispute resolution process (the manual of when-things-go-wrong!). Finally, we decided that we needed to rethink our pricing assumptions entirely.

Our most important learning was that there was indeed life in our model. Despite the existence of several large, established freelance marketplaces there was clearly interest in a new player and a different model – even in its incredibly rough, non-Envato state.

For five weeks of investment, we had something far more powerful than a business case; we had proven revenue and tangible knowledge of the product space.

4. Building The Real Product

Our MVP got us some great learnings, but the brief was to build a marketplace, not a shopfront. So after a few weeks of learning, we took it down and work began in earnest on our long term product, Microlancer.

During the MVP phase, we’d been crafting a product roadmap of what a full-fledged marketplace would look like, what features it would need, what messaging would look like, and how it would all work.

We set about building an MVP of our full product – a Minimum Viable Marketplace, if you will. To do this we tested every possible feature, bell and whistle against two harsh product tests:

  1. Is it actually essential to a working marketplace?
    Our company has a history of marketplaces, so there were lots of pre-existing ideas of what they needed. Some of these were obviously not needed for launch, like forums. Other features were not so clear cut, like ratings and reviews. These are the trust signals that make a marketplace work optimally. But can you actually facilitate marketplace transactions without them? Well, yes you can. So we didn’t build them for launch.
  2. Can we build it just in time?
    If something was essential for the marketplace to function, we then asked if it actually needed to be working and available from day one. For example, we knew an essential component of a freelance marketplace was a system for freelancers to withdraw their money. But we also knew nobody would be withdrawing on day one since they hadn’t earned any money yet. So this piece of code was actually built after launch, and just before our first withdrawal cycle.

Prior to the full launch, we had a private beta launch for freelance service providers. This pre-launch went live with only the basic infrastructure to sign-up and add services. This let us get real people in earlier to create content, without us actually finishing the whole product.

Using this disciplined product approach, we made a lot of difficult decisions to cut and cut until we had a working marketplace, if a somewhat basic one. That said, the areas we knew were important, like messaging, we spent time on. There’s an adage that says ‘build half a product, not a half-assed product’, and it held true for us.

5. Building Inside A Company

Unlike many Lean Startups, we were operating inside of an existing company. Building inside Envato came with both positives and negatives.

On the plus side, we had eight people on a brand new project. That’s plenty of resources to create a product like Microlancer. Of course, the drawback to that is that it’s significantly harder to get into the black with a full-fledged team from day one. Eight people are not cheap!

Our team had all the resources and benefits of working inside an established company with a great culture. But on the other hand, a piece of everyone’s week went to All Hands meetings, company social events, and other extra little bits of an organization that are needed when you have hundreds of employees.

We had a great company environment that allowed us to move fast, uninhibited by a lot of team structure, and with a direct line to the CEO. But on the other hand, we came in with a weighty responsibility to our community and legal and financial governance were a big deal from day dot.

Change inside any company, even one as youthful and energetic as Envato, comes with a bit of trepidation and needs extra communication. That meant we had stakeholder management and comms work all along the development period. People around the company wanted to know what this new product was, what it meant for the company, how it would affect our existing products.

When we launched the product, we had an absolutely massive audience to draw on, to promote to, and to help kickstart us. We also had a great brand that lent us immediate credibility. On the flip side, there was a large community who also wondered what this new product was all about. If we failed, we’d do damage to the company brand, so the stakes were higher. And being an established company meant we had to pay more attention to things like security and fraud than we might have if we’d been fresh on the block.

For me, the strengths of being part of the Envato company far outweighed the drawbacks. Envato is a dynamic place to build a product, our team was given lots of autonomy, and the support from the company and other teams gave us extra code infrastructure, mentorship, ideas, and know-how. Most importantly, our community helped us test the product and gave us the chance to learn and change, before telling the rest of the world all about it.

The Microlancer Team in 2013
The Microlancer Team preparing for launch

6. Launch

On April 3rd 2013 we officially launched Microlancer. Our private beta meant we launched with two hundred services ready to sell, and on our first day, we hit 5 sales and $210 of revenue. The launch was a success, and although we did hold a collective breath for the first sales and initial feedback, it was considerably less stressful than a non-lean launch would have been.

Our MVP, and our lean product development approach, meant we had some answers up our sleeve. It meant we’d already learnt from a few mistakes, changed our pricing strategy, planned ahead for our service providers, and come in prepared.

Being lean doesn’t stop at the MVP. We’re still using the principles and constantly test ourselves and our assumptions every day. It’s all about having clear and easy to measure goals, doing enough to test them, and being able to adapt and change based on your learnings. One of my favourite sayings is ‘Don’t let perfect get in the way of better’. This really helps us make decisions about what’s ready to go, instead of procrastinating over pixels and code that nobody else will ever notice.

Since the launch, we’ve been growing steadily, and six months in we’ve hit a run-rate revenue of a million dollars a year. We’re doubling every twelve weeks, and we’re excited to see where Microlancer will take us. Using the lean methodology we can respond quickly to the needs of the market, and hopefully provide an innovative product to a larger and larger audience.

This article was originally written by the then-GM of Microlancer, Layla Foord.

Check out other interesting blogs from Envato:

Do you find this article useful?
Related Posts
Envato Elements: Millions of creative assets. Unlimited downloads. One low cost.Get Unlimited Downloads