Startup to Exit: Lessons from a Hardware Founder
Startup to Exit: Lessons from a Hardware Founder
Building hardware businesses: Prototyping, fundraising, hiring, scaling, M&A and more, single-threaded leadership, bootstrapping companies, jobs, events
Friends, happy Friday and welcome to Startup Pirate #88. This is a newsletter about tech and startups with a Greek twist. If you haven’t subscribed, join 5,030 readers by subscribing here:
Startup to Exit: Lessons from a Hardware Founder
Super excited to host George Kalligeros, founder of Pushme and now VP Hardware at TIER, to discuss building hardware businesses. This is one of my favourite conversations to date as we go deep into a number of topics:
How his work at Tesla and Bentley set him up for founding his own startup
Converting bikes to electric easily and cheaply and doing things that don’t scale
Going through pivots and riding the micromobility boom
The M&A process with TIER and others
Best practices for hardware prototypes
Things he’d do differently in fundraising
Learnings and challenges in building within a hypergrowing company
Must-read books for hardware entrepreneurs
Let’s jump in 👇
George, you started your career at Bentley and Tesla. How did these experiences prepare the ground for starting your own business?
GK: Both experiences shaped me in critical ways and, in part, contributed to my pursuit of entrepreneurship. Bentley was my first real job – I was trained as a mechanical design engineer and worked in a mature product development process. However, the key learning for me was cultural; the corporate mindset gravitates to derisking delivery, and that stifles innovation and creativity. I wanted to experience the polar opposite in the same industry; hence, I became obsessed with joining Tesla.
My time in the valley was eye-opening in many regards, particularly around the speed of development and getting exposed to startups. Tesla set an incredibly high standard on hiring, attracting top talent from across the globe. Elon would frequently review the hiring pipeline and flush it if not satisfactory. So, great people were a key ingredient, allowing processes to be minimal and fluid. There was a strong culture of taking pride in the product, which rallied people to deliver. I also met founders socially and internally at Tesla. Elon often met with engineers working on new ideas, such as electric aeroplanes. These were the brightest engineers who looked to hire internally, so many engineers perceived founding or joining a startup as the ultimate frontier.
The hustle of the valley was also different; people from all over the world flocked to the valley to build startups. The most memorable experience was when a composites company’s CFO set camp outside Tesla’s office in Palo Alto, trying to meet Elon. Security surrounded him as he tried to talk to anyone from engineering. He gave me a leaflet to put on Elon’s desk, pitched me ruthlessly and explained that his company would shut down unless he got traction. He didn’t get to meet Elon, but an engineering team did, and I think he later even got a small pilot. It was mind-blowing for me at the time – everyone took work extremely seriously. Overall, through both experiences, I established myself as an engineer and set founding a startup as the ultimate challenge and an eventual north star.
What was the inspiration and pain point you were solving with Pushme?
GK: Pushme changed scope a couple of times but originally started as my Master's thesis at university – I had just returned from Tesla and wanted a blank canvas to design an invention. I have always worked on bikes and believed that e-bikes were a great urban mobility mode but too expensive for the mass consumer. With around 1 billion pedal bikes worldwide, I thought to design a device that converts them to electric easily and cheaply. The thesis yielded a prototype, but my hope was still to return to Tesla and the US. Fortunately, I couldn’t get a visa and therefore committed to founding Pushme after raising an entrepreneurship scholarship from the university to commercialise the invention.
We initially targeted food delivery couriers using conventional bicycles – electric assist and range were critical for them, as they could do more deliveries and earn 30%+ more daily. Deliveroo embraced the idea, and we raised a Department for Transport grant to launch a local pilot of 10 devices. During the pilot, we realised that couriers covered 100km+ in a day and, therefore, needed to recharge multiple times per shift. The solution of a huge battery was inconvenient and uneconomical, so we set up a recharge service in Dan’s (my co-founder’s) flat, where couriers would ring the buzzer, and we would run down and swap their battery “pit-stop” style. That’s when the idea of the Powerbox was born – we could build a battery vending machine placed inside restaurants that couriers would swap batteries from when picking up food. This would allow the battery to shrink in size, the device’s cost would be reduced, and we could allow restaurants to sell energy. In fact, we could sell the device at cost, acquire couriers quickly and sell energy-as-a-service for our business model, which is what our startup organically became.
Pushme initially targeted on-demand delivery to power the e-bike fleets of Deliveroo, Uber Eats, etc, before pivoting to micromobility. What were the reasons for this decision?
GK: Once we arrived at the energy-as-a-service model, we wanted to tap into pools of swapping demand through fleet partnerships. We understood the couriers’ pain points well – especially since Dan worked at Deliveroo prior – and there was strong interest from delivery companies to deploy our e-bike device and increase courier throughput. However, couriers were self-employed, which means that Deliveroo could not be seen to provide an employee benefit through, e.g. subsidising the device. The value we could extract from delivery companies was limited, and we had to sell to couriers B2C.
The challenge was that couriers were cash-strapped and seasonal, making it hard to commit cash upfront on a device. We launched a marketing campaign which produced some sales, but the initial traction was deflating. Couriers wanted access to the device on a pay-as-you-go basis, but raising debt to rent out devices for an unproven product with unknown residual value was a no-go. Consequently, we decided to look elsewhere for demand. Interestingly, sizeable companies were built in the space, e.g. Zoomo ($60M Series B in Q1 22) leased off-the-shelf e-bikes to delivery couriers successfully and built a sticky custom product in the segment later.
Luckily, European micromobility was taking off in 2018, proving to be a much larger and more stable swapping demand for us. At the time, vehicles needed recharging daily at a cost of €8-10 per recharge, which accounted for more than 50% of their ops cost. The dominant ops model then was to collect vehicles daily, charge them in a central depot, and redistribute them in the morning. Our proposition was simple – we would place Powerboxes in central locations across the city and incentivise users of e-scooters to swap the battery in exchange for a free ride. We coined the term user-swapping. Our model promised to reduce recharging ops cost by 10x.
The proposition resonated with micromobility companies, and it felt like a better place for us to build in, so we decided to pivot the product slightly and build for this application.
In late 2019, Pushme had signed up $4m in ARR when you decided to enter a strategic partnership with TIER and get acquired a few months later. Can you share more about this decision?
GK: After the pivot, we landed on traction, and things moved quickly. The micromobility industry was very fast-paced and, year-on-year, innovated on hardware. 2018 was about increasing vehicle lifetime, 2019 was about battery swapping, and 2020 was about unit economics and operational efficiency. We had been working on our Powerbox since 2017 and thus had the most advanced battery station for micromobility at the time; also, our proposed model of user-swapping promised the next era of operational efficiency, so our timing couldn’t be better. Within 6 months, we demoed our tech to all operators globally and were ramping up to launch city pilots to determine if users were willing to swap batteries and at what price.
The first thought about potential M&A came in an unorthodox fashion – Uber had recently acquired Jump and had a strong thesis on investing $1B in micromobility. When we pitched them user-swapping, it resonated strongly. They were already strategising on pushing the recharging task to users and were looking for hardware to accelerate deployment. They thought our tech offered the most advanced user experience, which they could “easily look to acquire”. We wanted to finish our product pivot before pitching our hardware. We flew to SF to pitch Uber 2 months later, only to unfortunately realise that by then, they were building a competitor product themselves! This uncomfortable blip made us think about how the industry will evolve and how we can best position our product and company for either scale or exit.
TIER was the first company to sign a Letter of Intent (LoI) with us. Even though LoIs are not contractual, they were negotiated like a contract, so we worked through pilot KPIs and scale-up plans at length. Depending on the level of user swapping and traffic through our Powerboxes, a pilot could still prove very lucrative for Pushme – we were charging €1.30 per swap and could drive up to 16 swaps per day per Powerbox – we could be breaking even each Powerbox in months.
After months of discussion with operators and pilots in the works, we set out to raise a €5-8M Series A. At the time, TIER was ramping up to launch battery swapping and was looking at the next strategic bet to improve unit economics and push for profitability. We were invited to spend an afternoon in their offices with the executive team to go through the pilot in detail and left with an agreement to explore the strategic partnership. Within 3 months, we had signed an SPA.
We decided to sell for a number of reasons. The number of potential micromobility customers was likely to reduce and consolidate. Also, given the fiercely competitive dynamic between operators, the vision of sharing the network across multiple vendors was unlikely, as everyone wanted time-bound exclusivity on innovation. This would ultimately see us reliant on too few customers, who could long term either acquire us or build internally. A pivot to another battery demand segment was difficult, as our product was customised to micromobility by then and integrating our hardware as a standalone company was going to be a big challenge on its own. Lastly, user-swapping was an unproven proposition, and the price point at which users would swap was uncertain. Ultimately, we would struggle to make our battery a universal standard that many operators could leverage, and taking on additional funding and raising expectations for an exit seemed like the wrong thing to do at the time.
Post-acquisition TIER capitalised the project, and we launched a 1,000 scooter, 50 Powerbox pilot in Tampere, Finland, with great success, achieving 40% user swapping within 3 weeks. TIER leveraged the pilot's success to raise its Series C from Softbank. The network was scaled to 4,000 locations across 40 cities and 12 countries, in stores such as McDonalds, 7-eleven and Fran-prix, delivering hundreds of thousands of swaps per year, making it the largest battery swap network in the west. Over the past 4 years, Pushme’s competitors have yet to scale a network of universal swap stations.
There’s this ongoing debate that software is easy to release and sell as a beta, but hardware needs to be “beautiful as Apple products” before it’s shipped. Are there any best practices for building a hardware prototype?
GK: Software is easier to release as Beta because you can continuously deploy code to feature-up, tune and debug the product. Hardware is also fundamentally developed in an iterative process; still, the main difference is that once hardware is shipped, the physical component cannot be easily updated. As a result, the product needs to be debugged upfront and be feature-complete for the scope of its first launch, which makes the release cadence significantly slower and the product much more substantial and complete in comparison.
Startups in the early stages need to optimise for time to learning. Every hardware product takes 3 iterations to get to the target state: first, you launch the product (V1), then you fix the product (V2), and then you fix the business (V3). With V1, you basically put the product's first version out into the world, with inherent flaws and bugs that can only be discovered once the product sees real-life usage. The team learns what broke and went wrong, finds new ways in which the users use the product and builds a V2 to be technically stable and product-market fitting. Once that has gone well, V3 is about optimising the unit economics of the product – supply chain, de-feature what’s not needed, design for mass production, etc. The process applies to every product, every company, every time. As a result, it’s oftentimes pointless to optimise the MVP as it’s likely to evolve anyway. If you’re not ashamed of your MVP, you launched too late.
Regarding some practical advice for effective hardware MVPs, I suggest 4 strategies. First of all, it’s vital to aggressively de-feature. Focus on the functionality the hardware needs to offer, and don’t be carried away building nice-to-have features. The biggest time trap is to optimise something that shouldn't exist in the first place. For instance, in the first pilot we launched at Pushme, we used largely off-the-shelf hardware, prototype materials, and the inside of the device was a mess of tangled wires; users didn’t know. Secondly, pilot the product at a small scale first. If you have bugs in your product and scale quickly, you’re also scaling your bugs. We had 2 instances with Powerbox V1 where we failed in our first 50-unit batch because our manufacturer had replaced an electronics component on the PCB with a domestic Chinese replacement of a different spec. The whole factory shut down when we plugged the first unit into power! We reworked the 50 units in a couple of days – it wouldn’t be the same for 10,000. Third, lean on firmware updates as much as possible. Firmware is easy to update over the air and can fix hardware bugs in creative ways. Lastly, over-engineer your platforms for an MVP – no need to right-size the electronics or de-instrument. If you have a bug that could have been solved with an over-the-air update or need to refactor your code because there’s insufficient compute, you’ll regret aiming for an elegantly sized system.
Which parts of your product did you outsource to a third party?
GK: I think a level of outsourcing is essential across the company’s cycle, especially in the early days. Outsourcing is a balance between speed, cost, and IP. When a task is too specialised, the core team will lose time trying to learn to execute it. If it’s not critical to your product moat to have the capability in-house, an external expert can usually get it done quicker and with higher quality. Also, during the resource-constrained early days of a startup, you have very limited roles to hire, so it’s best if these are core to your product and utilised to the maximum. In general, early-stage startups need to optimise for output.
At Pushme, we hired a strong core of hardware and software engineers that could execute on building and industrialising our tech, but anything we lacked skillset on, we didn’t hesitate to outsource: industrial design, electronics design of safety critical systems, certification and compliance, IoT security design, pen testing and more was all knowhow we brought in from an array of externals.
As the company matured, especially post-acquisition, we transitioned from optimising for output to optimising for outcome. Our lean and efficient team was overdelivering on the volume of work, but with increasing complexity the ball started being dropped, so we started staffing more narrowly defined and duplicate roles. We also vertically integrated some of the functions that we outsourced prior. We exchanged efficiency in staffing for guaranteed delivery of outcome.
Switching gears to fundraising. What would you do differently if you were a startup CEO fundraising again today?
GK: When I started Pushme, I didn’t invest enough in my founder education. In fact, I read all the books on fundraising while at TIER! Accelerators helped provide a framework, but the second time around and with more perspective, I would take a different approach.
Assuming I’m building a hardware startup from scratch, I would first look to structure my fundraising ask per stage such that I have enough capital to execute on my roadmap; hardware is costly and treacherous, and even though we did a lot with limited capital at Pushme, I have seen what it takes to build hardware and would prepare for that. Secondly, I would pick funds and partners more selectively. As an inexperienced founder, I spoke to anyone who would listen. Even though hardware and deep tech are resurging, I would narrow my outreach to people most likely to resonate with what I’m building. Third, building momentum and going for coffee chats widely in my industry (without a deck and before fundraising) to meet every relevant investor and get their thoughts on the venture. I would do it consistently and to the point that most have heard of my company and receive frequent updates. Then, once I’m officially fundraising, I would look to close swiftly and with people I know are likely to back me and I see myself working with.
What are the main lessons learned from hypergrowth organisations like TIER and leading an 80-person hardware team?
GK: I had a very interesting journey post-acquisition of Pushme. TIER capitalised our startup and successfully scaled the product across Europe within a year. Once the TIER Energy Network was operating in 4,000 locations, I focused on building the hardware team and developing TIER’s platforms of vehicles, batteries, IoTs, and infrastructure products.
There were many learnings and challenges in building within a hypergrowing company. As we started more projects and optimised for outcome, we hired at an accelerated pace. It was challenging to consistently hire good people – the distribution of available talent was a narrow slice of very high calibre talent and a vast base of average talent. Interestingly, many of our best hires came through network and recommendations. It was challenging to keep a high standard, and compromises happen when pressured to fill a role.
Getting hiring 100% right is impossible – you generally want a 70-80% hit rate. This means you need to be prepared to make adjustments when the hire isn’t right. A bad hire is much more impactful than a good hire. Another thing that tends to happen is that the best individual contributors become managers as the teams grow and the organisation matures. The downside is that unless you appropriately backfill talent in the IC position and provide effective management training, you have lost your best IC and have a manager with no experience on the job. Often, many young managers will float to leadership and learn on the job, which needs to be centrally managed.
As the team scales, communication becomes a huge challenge. Every person you add to the organisation needs to be onboarded, kept informed and engaged, have their opinion heard, etc. The admin overhead in properly running bigger teams without management debt is exponential, and it all costs speed. As the team grows, and each manager can only support 7-8 direct reports, the organisation scales with more middle management and one’s leadership job changes again. Eventually, hiring itself is delegated to the people below, and the nature of the work shifts from executional to strategic. At such scales, structured accountability and performance management become essential, as Price’s law arises – the square root of the number of people is responsible for 50% of the productive output, i.e. 10 people do half the job of 100.
Of course, it’s not all challenges. It was fascinating to design organisations and see how product integration follows team communication. It was inspiring to hire talent way more technically capable than you, and ultimately, it was majestic to travel around Europe and see your products operating in the flesh.
What are your top must-read books for hardware entrepreneurs?
GK: I would recommend reading “Product Realization: Going from One to a Million” by Anna Thorton. It’s a tactical book that discusses industrialising, which I took inspiration from when building the team. I would also recommend “Build” by Tony Fadell. Tony was early at Apple and built the iPod, iPhone and later founded Nest. It’s more generic on entrepreneurship but has some very insightful points on hardware building. Lastly, I enjoy tactical entrepreneurship books, such as “The Great CEO Within” by Matt Mochary, and more classics, such as “The Hard Thing About Hard Things”, “Zero To One”, etc. I don’t usually hold a ton of factual info from them, but they serve as a source of inspiration and perspective.
That was really insightful, George! Thanks for that.
GK: My pleasure, Alex.
Jobs
Check out job openings here from startups hiring in Greece. The list now has 544 jobs from 99 companies.
News
iCOMAT raised £8m to create a new fully automated facility for the production of space structures. (link) You can learn more about iCOMAT in our past interview here.
SeeChange Technologies raised £8m for AI-driven retail solutions. (link)
Cybersecurity company SPHYNX raised funding from Phaistos Investment Fund. (link)
Eurobank entered into a strategic partnership with fintech company Plum, investing €5m for a minority stake and another €5m, subject to fulfilment of certain conditions. (link)
Defense AI startup SOTIRIA Technology was selected by NATO's Innovation Accelerator. (link)
Four new funds with sizes €150-200m are in the making to invest in Greek high-growth companies. (link)
Resources
Babis Makrynikolas, SVP Product & Pricing at Blueground, on the importance of focus and single-threaded leadership. (link)
Generative AI meets Disruptive Innovation Theory and themes for first-time founders from Alex Angelopoulos, MBA at Harvard Business School. (link)
Discussing the latest developments in AI and crypto with Vassilis Tziokas, Head of Enterprise at Matter Labs. (link)
From manually provisioning and maintaining infrastructure resources to fully declarative Infrastructure as Code by Theodore Kirkiris and Konstantinos Rousopoulos from Workable. (link)
How AI is reshaping online shopping with Angelos Stavrakis, founder & CEO of SafeSize. (link)
Understanding the backbone of farming operations with George Varvarelis, founder & CEO of Augmenta. (link)
Discussing raising funds vs bootstrapping for your company with Antonis Kalipetis and Paris Kasidiaris. (link)
Events
“Testing strategies & frameworks and Tips for crash-free mobile apps” by GreeceJS on Dec 5
“HR Scaleup Summit” by Startup Pathways on Dec 5
“Unveiling four captivating Product stories from the Hack The Box team” by Product Community Greece on Dec 12
“Kubernetes Athens vol21” by Athens Kubernetes Meetup on Dec 13
“19th Athens Laravel meetup: Powerful Search” by Athens Laravel Meetup on Dec 14
“Microsoft Founders Day” by Microsoft on Dec 14
That’s all for this week. Tap the heart ❤️ below if you liked this piece — it helps me understand which themes you like best and what I should do more.
Find me on LinkedIn or Twitter.
Thanks for reading,
— Alex