Case Study: ElectroNeek Was Able To Find And Deepen Their Product-Market Fit Through Choosing The Right Customer Segment To Develop For
Case Study: ElectroNeek Was Able To Find And Deepen Their Product-Market Fit Through Choosing The Right Customer Segment To Develop For
One does not simply stumble upon product-market fit. True PMF must be durable, deep, and lead you to bigger markets over time.
Author’s Note: My apologies for this Case Study coming out so late.
Introduction:
Modern corporations perform more of their operations digitally. Great volumes of data are still collected, recorded, and stored in spreadsheets and databases manually. These routine tasks take workers away from working on higher-priority issues, leaving the opportunity for more value to be created on the table. Dmitry Karpov, Sergey Yudovskiy, Alexey Astafiev, and Mikhail Rozhin, believe with robotic process automation (RPA), businesses can increase employee productivity by eliminating these mundane tasks, starting ElectroNeek as a result. ElectroNeek is an RPA startup developing digital assistants and digitized workflows for startups and information technology (IT) teams. The startup is currently based in San Francisco, California.
Executive Summary:
Problem: Avoiding False-Positive Product-Market Fit
A key aspect of achieving product-market fit is that the resulting processes underlying the business model and technical development result in repeatable customer acquisition at (ideally) a low cost. Many founders may stumble on what “seems” to be PMF in the short-term but is not truly it in the long-term - time separates the wheat from the chaff.Market: Understanding The Specific Needs Of MSPs
ElectroNeek’s deep market research helped them discover that beyond their initial hunch that SMBs and startups were generally the right types of customers to target, a specific customer niche of managed service providers (MSPs) provided the best test for them to find and deepen their PMF.Solution: Deepening PMF Around MSPs, ElectroNeek’s Core Customer Group
ElectroNeek found MSPs as an ideal customer type, but now they had to not only acquire them, but also retain them over the long-term to truly determine whether they had achieved PMF. They did this by focusing on ensuring MSPs were successful using ElectroNeek, making it more likely for the former to come back to the latter time and time again.Team: Focus On The Issues, Not Personalities
One underrated aspect of team formation in the earliest days of a startup is the social intelligence of the founding team, which can make or break a company. Are the teams emotionally intelligent to avoid personal attacks amid a heated debate about a new feature to be deployed or a potential pivot?Fundraising: Sell Your Ability To Find And Deepen PMF To Investors
Raising from venture capital firms is 99% narrative, thus, a founding team has to be able to sell their ability to find PMF, and then deepen it to establish durable traction at the seed and Series A stages, respectively.Takeaway: Find A Customer Segment That Validates And Sets The Stage For Accessing Bigger Markets
ElectroNeek’s success comes from their choice of customer, MSPs, that allowed them to not only find PMF, but deepen in and establish a foundation for serving an even greater set of customers in the near future.
Case Study: ElectroNeek
Problem: Avoiding False-Positive Product-Market Fit
Tell me about a problem or set of problems that you’ve had to solve on your journey to product-market fit.
One of the hardest problems for my founding team and for many other founders is potential confusion between PMF that accelerates sales and well-executed sales campaigns that succeed due to the founder's energy or due to just an unrepeatable coincidence of events and circumstances. With the latter, you grow but not as fast as you expect and struggle to find a model to scale. With PMF, you may have a lot of processes not working at their desired efficiency, but you see growth because your address real pain points with a feasible articulated solution. Without PMF, even well-oiled processes do not bring the company to the desired state. That's why a 'false positive' PMF can lead to critical mistakes and slow the startup when speed is everything.
Why were these problems so critical to solve? What was it like personally struggling to overcome these challenges to achieving PMF?
The effective customer feedback loop is a systematic solution for these types of problems. In our own experience, we were segmenting customers into cohorts and approaching them (for value proposition and feedback) as different buyers' personas. To illustrate it, let me explain how the Robotic Process Automation market works.
When we moved the go-to-market (GtM) focus from end-users to MSPs, we as founders got back to personal customer/prospect interviews to understand what their pain points were with other RPA vendors. Of course, we listened to existing MSPs among our clients because they committed to working with us earlier, and it meant that we somehow already addressed their pains; we just needed to understand what exact pains are there and what remains unsolved. Later we switched the paradigm of thinking about customer value - MSPs buy from us to build their own business, get new revenue, so let this be a success metric for us - how well our clients make money using our product and support. It's not about addressing a pain (unless someone takes your product and goes out there to sell it they have no pains, but it’s more opportunistic framework), but about maximizing the chance of your client to succeed in growing business (we price based on developer seat: more business our clients win more developers they need).
…a 'false positive' PMF can lead to critical mistakes and slow the startup when speed is everything.
Market: Understand The Specific Needs Of MSPs
Let’s get deeper into the pain point or points you were trying to solve. Imagine I’m a customer thinking about using your product or service. How do you go about understanding my pain and creating a solution to address it?
Robotic Process Automation, or RPA, is a type of low-code/no-code software for automation of repetitive tasks that humans do on a computer, like form filling, data migration, and formatting. To build an RPA workflow means to develop a rule-based script for a bot that will imitate the actions of users in target business software, like a browser or spreadsheet. To implement RPA means to select a process for automation, build a process map, develop workflows using RPA software, and deploy 'a bot' that will execute workflow taking control over a mouse and keyboard, when launched or when the execution is triggered by a certain action, like incoming email with customer order.
The critical players in the market are RPA vendors, with a few deca-unicorns leading the herd and RPA Integrators that do RPA implementation as a service for clients. It's important to note that historically most RPA implementations are delivered by professional services firms, Integrators, because the technology is still new for many companies, and they want at least their first projects to be delivered by experienced RPA developers. Because only Enterprise clients have many processes to automate, most RPA Integrators historically have been focused on Enterprise clients, so by 2018, 90%+ of all RPA projects globally have been delivered by large multinational professional services firms.
We started ElectroNeek to democratize access to RPA for smaller companies in Mid-Market and SMB. Our initial hypothesis was that RPA products are quite complex because they focus on enterprise requirements and have been a heavy lift for junior and mid developers in smaller companies, so if we build a similar product with great UX, we will have a strong PMF. Our original approach was to focus on end-users as a target market, "sell" the story of building "robotization" as a capability in each modern company.
It turned out to be that today such companies, that can create these capabilities in their IT teams exist, but they are a minority, and a bigger automation market exists - companies that can benefit from RPA a lot but would never create an internal RPA developer position and use complex software products. They just don't need it like they don't need to have internal cybersecurity, CRM implementation, backup infrastructure engineer, and many other roles that can be delegated to a managed service provider (MSP) that hire IT professionals to take IT products and customize/manage them for their clients. I know that small US companies increased their spending on IT services from MSPs last year by around 15%; Datto (security solutions for MSPs) reported it in its 2020 State of MSP report - $5B company that sells exclusively to MSPs.
So ElectroNeek became the first and so far the only RPA vendor for MSPs, who benefit a lot from the product architecture we originally designed for companies that want to scale RPA internally. In this architecture, we unbundled the software used to run a bot built in our IDE from the rest of the product and made it free to download, so whoever has a customized, ready-to-use bot can run it for free in any IT infrastructure. Our competitors, the whole RPA market, charges for this - for the ability to execute automation, to run bots.
We graduated from YC with this model, but we didn't realize by that time how beneficial it is for MSPs that can build bots for dozens of clients and easily ship to them.
In our specific case, we talk to managed service providers (MSPs), and we ask them if they are already considered to have RPA practice. If not, we ask why and these are very interesting insights about lack of knowledge; if yes, we ask them very direct questions - are you happy with its growth? Usually, they say that there are issues with costs for end-users - with other vendors end-users always bear both licenses cost, so only 50-70% of revenue goes to MSP, and many projects are not economically viable in the first place. But if you remove the software costs component from the end-user, MSP clients, they are likely to go into the deal. Over time, we found this to be very important for MSPs when they decide to invest in products of new vendors to make money from implementing them in the market:
Ability to deliver/demonstrate best value/ROI for their own client
Leads
Quality of support
Productivity of their RPA developers (can one developer work with 5 or 10 clients are quarter - the answer is a game-changer)
Security, Technical stability, and performance
Training and certifications
Marketing with vendor
Assuming you’ve managed to address the pain points I face as a customer, what additional information did you discover in your journey to PMF that there’s a large market in need of a solution to the existing problem?
That product on its own is not the whole solution. It's part of the solution.
A solution for us is something that the client buys to achieve own success, and the product is a software component to this. We discovered that MSPs want content, collateral, and services from us as a vendor to be successful (build and grow new revenue streams). We offered potential customers multiple tiers and flexible, customized packages, including product configurations and a number of developer seats, support, training, etc., and then standardized tiers based on popular demand for different types of MSPs and their learning curve with RPA. And then retrained our account executives to narrate the content of tier to the needs of different buyers, so they can be advisors to prospects rather than just sales professionals.
How did you narrow your scope of what portion of the market you wanted to tackle first? Who did you decide would be your first beachhead customers and why?
We realized that those customers are successful that build a lot of bots (so they invested enough in training and getting to learn all features). So, where can these professional RPA developers, even theoretically, be? In enterprise, big consulting firms, and MSPs. But framing it this way took a journey.
Segmentation is critical in such market types as MSPs. Instead of segmenting them by size or geography, we initially sliced the market by the software vendor that an MSP uses to go to market (can be multiple). For instance, Salesforce implementation partners, one of the largest system integration communities in the US. We landed working in partner ecosystems of leading accounting software vendors because accounting systems need a lot of manual data entry or costly integrations that are hard to maintain. So we partner with top vendors (in this case Sage, #2 globally, build automation demos using their products, market among their implementation partners (there are 4,000+ globally) who already offer ERP or IT integration services and offer them building a new revenue stream. That is building RPA bots for their Sage software clients, automating feeding data in or out accounting systems on UI level. Like taking all customer data from QB product and moving it into a new account on Sage product.
For a vendor like Sage, there is an extra benefit of having MSP building and RPA workflow on top of Sage product. It is an increase in customer stickiness - they not only bought ERP from you (in Sage’s case - X3), but also invested in building an automation layer. The switching cost to a competing ERP will be higher, because new RPA workflows would be required to set up. We now understand these insights because we talked a lot to both vendors of SaaS products with relatively high switching costs and MSPs in their network.
Solution: Deepening PMF Around MSPs, ElectroNeek’s Core Customer Group
How did you build your solution to maximize its relevance with the customer and ensure product-market fit? If you haven't found PMF yet, what have you learned? What are the blockers for getting to PMF?
Once we achieved small-scale but stable sales to target buyer personas, MSPs, we focused on success management and what it can do for a customer as a major source of market feedback to deepened PMF. We offered potential customers multiple tiers and flexible customized packages, including product configurations and a number of developer seats, support, training, etc, and then standardized tiers based on popular demand for different types of MSPs and their learning curve with RPA. And then retrained our account executives to narrate the content of tier to the needs of different buyers, so they can be advisors to prospects rather than just sales professionals. We listened to a lot of demos to understand prospect feedback on different value propositions and iterated from there. Once you deepened (increase value for a specific client cohort) PMF, one-size-fits-all doesn't work in B2B, in our experience.
What are some of the things you did that “didn’t scale” to shape your solution today?
Pitching to prospects, running customer interviews, looking deep into the support ticket system, analyzing recordings of demos.
How we build products: we aim to maximize no-code functionality because it improves an RPA developer productivity. We offer "do it with custom code" options in the product and can learn what exactly people try to add on top of our standard functions. So we simply look where no-code can replace code and add this as an "action" for the RPA bot. For instance, think about a standard feature "insert current date" in a documentary feature for a bot that fills a contract template. It seems to be a pretty standard need, so we can envision that without deep customer development. But when we see a support request from an inexperienced IT professional or a custom code that solves the following: "insert current date + 30 days," you think, ok, this is what people want, a standard "insert current date ±X" function or upgrade existing ones. If you don't have such a function, a user should understand variables, put a few lines of code, etc. Standard functions make building such a bot faster.
What did you learn to best engage with your customers? How did you build a tight feedback loop with your customers to rapidly improve your solution to their problems?
We do have four teams that interact with prospects and customers - sales, customer success, support, and marketing, and all four have feedback loops maintained by one of the founders or VPs, we synchronize on findings weekly to form inputs for the CEO agenda and product team sprints. At the same time, the customer success team has direct communication with the product team to better understand near- and long-term roadmap so some of the future features can be shared with top-tier clients, typically big MSPs or technology consulting firms.
Walk me through how you landed your first few customers as you were building your product or service.
Sergey Yuodvksiy, co-founder and CEO, put together a landing page with "Book a demo" CTA more than three months before the idea to actually start a company in this space crystallized. He got many demo requests for the first value prop hypothesis ('affordable RPA' for mass-market). So we started commercially with inbound lead generation - landing pages (GDN, social) and website (SEO), to acquire leads with "Book a Demo" CTA. It worked well in all geographies where ElectroNeek started - Europe, North America, LatAm, India, and Australia.
That product on its own is not the whole solution. It's part of the solution.
Team: Focus On The Issues, Not Personalities
If you have a cofounder, walk me through a time that you two had a conflict. What was it about? How did you handle the situation? What was the resolution, and how did it impact your working relationship with your cofounder?
Healthy conflicts are important and useful for co-founders, but keeping them 'healthy,' which means focusing on the matter and issues but not the personalities of each other or team members, requires certain social intelligence and investment on each side. A good resolution example would be if you are running in circles on a call, stopping the discussion, and exchange thoughts and arguments over email - the written communications format itself is great for keeping conflict 'healthy.' Works for our group, but I know that for some co-founders letting it blow up in a hot discussion is the best way to let it go and move forward. Taking a personality test can be a good idea if you have a co-founder whom you don't know well for a while.
What key qualities did you look for in key early hires to increase your chances of discovering product-market fit, and how did you prioritize what types of hires you needed to make first?
Intellectual curiosity, default-to-action acceptance culture (don't ask permission for every new thing you want to try), ability to derive conclusions from small statistics, and understanding where it can't be done. Supportiveness of colleagues, ability to prioritize and have fun under pressure.
We hire (or try to hire, without marketing shine:) only the people we want to invest our time and energy in, and this is the only way to scale as a company. Not every hiring decision is right, and it's personal growth for each co-founder to become better and better in hiring for the roles we never managed in the past. It comes to the culture, often hard to test in the interview or first few months.
Everyone in the company should think in the same way - build your own horizontal and vertical teams of talent you want to work with, be better with hiring and contribute to culture.
Building culture became much harder since the remote work kicked off. We, as founders, got positive feedback from employees on supportiveness as a core of the culture we try to create. Supportiveness here means that colleagues worldwide will go the extra mile for other colleagues because they know that someone is picking up their work at the end of the day. So what they do today will be multiplied by that person and get back to you the next day with a bigger amplitude.
If there was a potential employee of your startup reading this Case Study right now, how would you convince them that joining your team is the next best step in their career?
Here at ElectroNeek, we are accelerating the future with no routine work, where people have equal access to the tools and data to maximize their own creativity and impact, accelerating the future with robots. It is a one-of-a-kind opportunity to become a part of the automation movement that is just starting and targets to free 40-60% of average office worker time! On top of that, unlike most of the industry that is focused on big companies and cost reductions, our team fights for the democratization of powerful automation technologies so they can be implemented in companies of all sizes with the help of MSPs. You will experience being at a focal point of the mass-market adoption of RPA because you will be empowering automation entrepreneurs from across the world, including those in emerging economies, to deliver affordable automation everywhere. You will help entrepreneurs build businesses and create jobs everywhere.
This mission and focus allow us to grow so fast. If you share this mission, come to join our team (we are hiring for many roles).
Healthy conflicts are important and useful for co-founders, but keeping them 'healthy,' which means focusing on the matter and issues but not the personalities of each other or team members, requires certain social intelligence and investment on each side.
Fundraising: Sell Your Ability To Find And Deepen PMF To Investors
How did you set expectations with investors at seed and Series A? What is the main difference in those expectations as your company grows from one stage to another?
I believe that the major difference is making investors sure of your ability to find PMF, even early revenue can be more a sign of the ability to sell (which is important for finding PMF) rather than a sign of PMF validation. At Series A, it's all about demonstrating the PMF with repeatable and explainable traction that the founders can extrapolate for future growth. Two completely different conversations and the founding team's value proposition.
How does dilution work as you go from seed to Series A?
I can't comment on this in our particular situation, but we learned that most B2B Series A lead investors are looking for around 15-20% ownership in the company.
I believe that the major difference is making investors sure of your ability to find PMF, even early revenue can be more a sign of the ability to sell (which is important for finding PMF) rather than a sign of PMF validation.
Takeaway: Find A Customer Segment That Validates And Sets The Stage For Accessing Bigger Markets
What are the key lessons have you learned so far from your journey to achieve product-market fit?
Don't be a hammer looking for a nail.
Pick up a customer segment where you can validate the pain point.
Validate the pain as founders, don't outsource it (you should listen to a demo recording in Gong rather than just look at the manager's report.
Making a specific customer segment happy and demonstrating this with traction is your PMF.
Having that segment scalable into a bigger, measurable market is your ticket to Series A.
What’s the hardest problem you’re facing now after solving the prior one(s)?
The hardest problem we face is hiring the best talent to design and support processes that scale and prioritizing resources between geographies.
Three Cool Founders You Should Know About:
Genevieve Ryan Bellaire, Founder of Realworld: Realworld is an education-first platform helping the next generation thrive on their journey to independence.
Rebecca Liebman, Founder of LearnLux: LearnLux democratizes access to fiduciary financial guidance by partnering with top employers to offer a leading financial wellbeing program that provides a high-tech, high-touch solution to help employees build a comprehensive, personalized financial plan.
Dasha Kroshkina, Founder of StudyFree: StudyFree is an online platform that connects students with international opportunities worldwide.
Previous F2F Case Studies:
Case Study: Navattic Is Finding Product-Market Fit Through Building Strong Customer Relationships
Case Study: Fisherman Founder Ameet Kallarackal's Trip To Catch The Product-Market Fit Fish
Previous Startup Spotlights:
If you enjoyed this article, feel free to check out my other work on LinkedIn. Follow me on Twitter @fredsoda, on Medium @fredsoda, and on Instagram @fred_soda.