Summary of this article can also be read in this presentation.
Ive been managing a business development (BD) team for 3 years now. During this time, i see that BD role can meant different things. In some companies, the role skews more to sales, in other it might be more to product development. There also stark difference from BD in big corporate versus in startup. The first one might be more to high-level strategic partnership, while the latter more hands-on with business operations and expansions.
In Amartha, i can summarize my work as developing new business by pushing ideas into rollout. In this post, ill share several of my learnings developing new product / business, starting from brainstorming scribbles in notepad, work the ideas into concept slides, running a pilot and finally decide to expand it in multiple areas.
Ill explain overview of Amartha business and current role of BD. Amartha, on a borrower side, is group lending serving micro-entrepreneurs. Due to our focus in serving unbanked, low-tech and cash-based segment, Amartha relies heavily on field officers. Hence Amartha is an ops heavy company. My BD role for the past year is to expand the core business both vertically and horizontally. Vertically means exploring new offerings to current customer base while horizontally means searching for new potential market for Amartha to goes into.
Therefore, there are several caveats on tips and insights in this article
- Amatha serve bottom of pyramid segments. Exclusively served women. All of them in rural areas. Less than half use smartphone regularly. Only a third have bank accounts.
- Amartha is an ops heavy company. Were an online to offline startups hence growth correlates with number of manpower.
- Software development time is scarce. Were dont have an army of sofware devs like the unicorns hence sprint slots needs to be deployed as effective as possible. My team almost always do lots of manual works first.
With these caveats in mind, lets jump into the content.
Business starts with ideas. In the idea stage, crucial thing to do is to understand what are the problems. In a brainstorming session, make sure everyone is on the same page. Having several slides of problem introduction might do, better if you can make everyone “felt” the problem.
One useful tools in this ideation stage is Design Sprint. I tried it several times and the process can give broader and richer ideas. However to do design sprint, you need to allocate five days with at least one C-level involvement. Nine out of 10 occasion, me and my team dont have that luxury hence what i do is take bits and pieces of design sprint method (e.g Start at The End, Ask the Expert, Crazy 8) and use it in 1 to 2 hour brainstorming session. Churn as much ideas as possible with your team and judge with your guts whether the ideas relevant to the problem.
More on design sprint can be read in this book (also available in Bahasa ) and also in this website. Design consultant AJ & Smart also have lots of tips on design sprint in their youtube.
Another method that i always use is to steal ideas from other markets. Look for similar product in ProductHunt, browse through the startups in CrunchBase and read reports and study case from CBInsights.
By this stage, you got list of several ideas in notes, google sheets or other formats. The next step is to pick one or two and then develop it into concept. Whats the difference between ideas into concept ? for me, a business concept needs at least these 5 elements.
- Users. Who is this solution specifically made for ?
- Value Propositions. What values do you offer ? Solving pain-points ? Increase income ? reduce cost?
- Product Definitions. What are the features of this solution ? Is this an app or not ?
- Operating Model. How to deliver the service to the users ? Who does what in the company for this to work ?
- Unit Economics. What are the growth drivers ? Revenue ? Cost ? Profit ?
Describe all of these in a slide each then you have a good concept document.
After you sculpted ideas into concept, next step is to validate it to real customer.The concept at this stage is all assumption. In fact, treat everything as assumptions until customer starts giving you real money.
There are lot of ways to do concept testing. I usually do these 3 steps.
First, create simple brochures or sales material based on the concept document. Second, talk to your target customer and offer them directly. Third, and this is important, ask for real money or commitment to pay. If you only ask, hypothetically, whether they pay or not, the answer is always yes (and its a lie). Ask for real money upfront, or if its not possible, ask for their phone numbers, personal email or KTP number.
By doing this, every customer rejection is real concern and you can dig-deeper from there. Iterate the concept based on these rejections.
To learn more about concept testing and doing user interview, here is a lecture by Twitch founder Emmet Shear. Interesting bits starts from minutes 20 above.
By now you have concept slides. It has been validated by doing early user interview. You’ve iterated the concept based on the feedback and felt confident about it. So whats next? build the slides into real thing.
Use the concept slides to talk with other teams in your organization to make this a reality. Since this is still an experiment, tell them upfront that this is an MVP and whats the fastest deliverables that you can get to sell this to real customer.
Yevgeny Brikman write a concise article on how to develop MVP. I recommend to read this to get better ideas on MVP.
Depending on the product and the company, making concept to reality can be as simple as talking to software developers. However in my job, i often need to talk with various team as described in above pictures.
Once you got MVP ready, time to run a pilot. Five pointers on this stage from me :
- Have your MVP ready. Develop your concept first.
- Set a success criteria. Pilot is an experiment. Define the definition of success for this experiment. What is the metric that matters to this new product ? user ? GMV ? transactions ?
- Set a budget. How much does this experiment will cost and how long ? I usually set this at 3 months, with monthly checkin whether to stop or not.
- Pick areas to pilot. Ideally more than 1 to test market variety. Pick two extremes as possible. Depends on the budget as well.
- Use small team. Product needs to be easily pivotable at pilot. A 3-5 core pilot team make decision making very fast.
- Launch immediately. Again, everything is assumption until user gives money. Hence, dont spent lot of time in MVP and launch immediately.
In running pilot, there are one concept that i really like to use : Do Things That Dont Scale.
Again, pilot is an experiment. You want to test whether this concept has some real business value or not. Its not wise to spend lot of resources (e.g development time, people) and lot of money at this stage. Hence do everything manually at first.
Deliver the service yourself, use ready made app, take the customer angry calls yourself, use google sheets as much as possible and if your pilot involve partners, integrate manually (e.g upload CSV, send order via Whatsapp). Do it yourself and be as close as the problem as possible.
By doing this, you and your team will felt the operational complexity by heart. After the first 4 weeks, when you decide to automate or develop features, you know exactly what to build.
More on this, go read this famous essay from Paul Graham.
Once you’ve got pilot (or pilots) running, heres five pointers from me to monitor the progress.
- Have a dashboard. Check daily progress on your success criteria
- Be supportive. Respond quickly both to customer and ops team feedback. Never let your ops / front liner / sales felt that they’re alone.
- Weekly review. Review metric, any hurdles, best practice every week with all team. In-person if possible or vcall. Take quick decision if there’s need for changes next week.
- Be on Customer Service Duty. Reroute every customer contact to you or the team. Better yet if you can answer them yourself.
- Be as close to the problem. If something doesn’t work, go in front of the customer and solve it.
Pilot is running well. One month seems good, two-months getting better. Now what? how do you decide its time to scale up ?. First, look again at your success criteria. Then look at weekly and monthly growth.
In last year Techinasia Conference, i attend session by Xendit founder, Moses Lo, on running experimentation. Every pilot needs to pass 7% growth weekly or 30% growh montly. More than that, pilot gets more investment (rollout). Less than that, pivot or scrap. This is a good and simple measure.
However, you need your own judgment as well. Does this really work? does it reach product market fit ? if yes, then you’ve got yourself a feasible business to rollout.
Thanks for reading. I hope its useful. Below are several other references on running ideas into rollout :
- Paul Graham – Growth
- Reid Hoffman’s – Blitzscaling lecture series
- Keith Rabois – How to Operate
- Stanley Tang – Do things that don’t scale
This essay is written based on my experience learning, managing and failing in Amartha BD team. Bits and piece of this knowledge was inspired in discussion with all current and past member of Amartha BD team 2017 – now. My kudos to these guys.
- Nadhira Ayuningtyas
- Saraswati Hassan
- Evi Teja Kusuma
- Szagibella Aprilia
- Giovanny Agnes
- Nadirah Syahnaz
- Ariandra Adipurnomo
- Sean Hambali
- Erald David
- Fajar Wicoro Jati
- Gisella Swastika
- Santa Yunita Gultom
- Suci Sarah Andriany
If youre enjoying this post and want to get updated content via email, subscribe via form below