‍

At the start of Startmate’s Accelerator program they say: “You won’t recognise your company and product by the end of the 12-week program.” 

When my co-founder and I heard this we had a little laugh to ourselves: “Ha, not us, we have paying customers!!”

But, they were right! By the end of the 12 weeks, we had resolved to change our product and the name of our company.

Curious about why and how we made this choice? And what happens next? This is part 1 of a 3-part series where I’ll aim to give you insight into our early-stage startup journey.

‍

Why?

Why would we change our Configure, Price and Quote (CPQ) software Flexile when we had beaten the largest competitor in the space in head-to-head bids more than once? Why change when we had happy customers and were growing? 

Scaling. That’s why. 

For those who don't know what CPQ is (you are not alone), it's a system that makes complex or high-volume quoting faster, easier and 100% accurate!

Implementing CPQ software is very resource-intensive, which is a good problem if you run a services business, but is a real blocker to scaling for a SaaS business. We looked at tackling it the way our competitors do, with outsourced service partners, but we believe this sets the wrong motivation. The services partner is incentivised to maximise the days spent on the project as this is how they make money. This can lead to overly complex solutions, or allowing the customer to fail and then billing them more to fix it. Cynical yes, but I have been burned by this as a customer.

Ultimately, to become as successful as we want to be, we need to be set up to scale. That means a product that is easier and faster to use and ideally provides for self-service implementation by our customer.

‍

How?

Our first planning sessions were on how to tackle this. How could we both maintain v1 of Flexile and get started on v2? What is the current roadmap for existing customers, can we maintain this, and how does it impact the need to seamlessly transition them from v1 to v2? 

Lots of hard questions, many conversations with customers, and some serious soul-searching later, we had a plan.

The main takeaway for us at this early stage was ’we only have so many resources’, especially development and product management. This forced us to think super hard about what would deliver the best bang for buck. 

Ultimately this lack of resources has set us on the best possible path of being super focused on what moves the dial for our customers.

The good news

Rather fortuitously, we had been contacted by businesses looking for a product and pricing management system to handle the complexity of pricing calculations and to sync with their other systems (CRM, finance, ERP, E-commerce, etc). All they wanted was to get out of spreadsheets and into a tool that would make it easier and faster to manage their products and pricing. But they just did not need, or want, to pay for the CPQ functionality in Flexile.

Win 1)

‍While rebuilding the foundations of v1, we were able to split off the product and pricing database as a separate product!

Win 2)

We had beta testers ready to go for our v2 product and pricing database, which allowed us to fine-tune the product without disturbing existing Flexile users!

Alright, now things are starting to feel like they are heading in the right direction… 

Well, except that we need to raise money to fund the extra simultaneous development of two products. Easy right? VCs are practically drowning in money. (At least it seems like it from reading Crunchbase!)

Alas, raising is still hard

So, it turns out that working on product and pricing management is not sexy. 

Whaaat? I know, super hard to believe. (We should have been in electric cars/fintech/crypto/saving the planet.) Unfortunately this means many VCs were not interested. 

Luckily for us, however, we met a great VC in Sydney (stay tuned for an announcement soon) that was interested in “pipes and plumbing solutions to fundamental issues that beset business”. Phew!

So, how many VCs should you talk to? 

For us it was as many as would take a meeting with us. Having said that, we had done our homework on not just who we thought might invest in our business, but also, who we wanted to work with. This meant that we met with about 20 VCs in total (actual meetings not just a chat), and amazingly, we ended up with a term sheet from our first choice!

At this point we had to decide: do we push harder for a better offer (conventional wisdom seems to be to shop it around), or do we just lock it in immediately? We elected to lock it in because THEY WERE THE INVESTOR WE WANTED! 

The hard-nosed salesman in me squirmed a little, but as a founder the long-term benefit of working with the best partner was always the right decision. It’s going to be a long journey and we want the right people on the ride.

‍

It’s a game-on situation!

1. Planning - Check

2. Customer feedback - Check

3. Funding - Check

4. Beta users on standby - Check

5. New staff (You may have heard it’s hard to hire developers at the moment. I can confirm this is 100% correct. So not a ‘Check’ yet.)

Okay, so we need to hire staff, but we also need to get started because the clock is ticking, and time is the enemy of all startups. In the end, we restructured our resources to commit as much as viable to the new product development and just get started. Check!

Out of all these points, it was the customer feedback process where we really had to up our game. We looked at what the pros in this space did and built a far more formalised interview process that we had previously. This was a game changer! 

We highly recommend a good interview script (we like this one), and recording the call for later playback, because sometimes it’s only after you rewatch a group of them that you pull out a key insight.

The bare bones

The key to moving forward was getting super focused on the absolute bare necessities we needed to build to get an MVP in the hands of our beta testers. 

Fundamentally, our product and pricing database ProductEngine needed to be a user interface for product/pricing managers that was easier to use than a spreadsheet, with an API that was so easy to use that a developer wouldn’t consider building their own.

The plan

It’s early February and we plan to have an MVP in the hands of our beta testers by March.

The three biggest problems we are tacking in the next few months are:

1. Product-market fit for v2 of our product and pricing engine;
2. Hiring; and
3. Growth.
   

Right now it’s the product-market fit that we are super focused on. If we don't get this right, then hiring and growth don’t even hit the radar and it's straight back to the drawing board. 

Our constrained resources have resulted in another great learning: focus on the next blocker and attack it with everything you have! 

Growth and hiring will no doubt be hard, but we have to earn the right to worry about them by first finding product-market fit.

By part 2 of this series, if everything is going well, we will have a prototype in the hands of our testers for feedback. If it’s not going so well, we’ll most likely still be building.

We believe that we have done the initial work and we know the core features required. We feel super positive about delivering the beta version in March. 

What could go wrong? 

As it happens, we have considered this, and our fallback is to drop this development and look at other ways to scale the existing CPQ product. We have some really cool ideas for a marketplace where users can download all their products to massively reduce onboarding time. So either way, we will keep fighting the good fight!