On Product Development

XLIV

28.04.2024

Founding a company may involve doing a lot of different things, but there’s only a few things that will actually drive the business forward, at least when you’re early stage. 

So, here’s a reflection on what seems to be one of the most critical parts of it: the product development cycle. 

Listening

To develop our product with Ultima, we started by simply listening. After all, we are selling to sales people, but none of us are sales people. So, we needed to learn as much as possible as quickly as possible.

We listened to 50-100 sales people before we even started guessing what a solution would be. At some point in there, we started coming up with hypotheses to test, and then testing them.

What that looked like was:

1) Listening—still the most important part

2) Brainstorming hypotheses and making them as an “MVP”

3) Delivering those ideas back to the person we listened to

Step 1, Listening, is pretty straightforward but critical; Step 2 is not quite as obvious. That’s about taking the listening and learning and then coming up with a testable idea as quickly and efficiently as possible so we can maximize feedback. Delivering that idea probably takes a bit longer than listening does, but is also highly variable.

Step 3 is quick but critical. It’s not a product pitch; it’s actually just the start of the listening process again. “This is feature x. We built it to solve pain point y by doing z.”

And then, we watch them use the thing and talk about it and start the cycle over again with more listening:

After doing this a bunch, you’re certainly close to having a solution for someone. Stop there, though, and you’re a consultant.

To clarify, step 2 is the most painful part of each cycle and can be much longer than either listening or explaining, but the goal is to keep it as bounded as possible. Still, there is a pressure for it to creep up in time cost. Presenting a pdf might be sufficient at the start, but building a front end might take a wee bit longer.

PRODUCT Development?

Again, this is PRODUCT development, not consulting. If this were consulting, we’d be done with the above diagram. Rinse and repeat forever, with some learning and domain expertise extracted from each interaction making the value of each subsequent solution delivered higher and more obvious from the start.

However, one thing we’re now working on is parallelizing feedback, so the cycles look more like this:

Now, as we have more people using our product, we’re pushing towards each cycle involving listening to more users and finding the common thread, the stuff that will actually make more of their lives better.

Admittedly though, this is a hard process, as we’re learning that some users should be listened to more or less than others, and we’re still early enough where we’re focusing on a handful of users and making them all as happy as possible. So, while we’re listening to everyone, we’re becoming very conscious about which feedback we actually implement.

With that in mind, part of the finding and delivering solution part illustrated above involves anchoring on what we know is true. The decision maker wants to increase revenue—does this feature or request help us increase quantity of items sold or the value of those items? And yes, we can increase the value of an item sold indirectly by helping target customers that are worth more to the sales team if they close.

So, all that is to say that we still look a bit more like the first product development cycle I showed. We’re still taking feedback from maybe one or two users and implementing it at the same time, rather than a bunch of users at once.

Sales?!

A sneaky take away I’ve picked up from this is that product development seems to be a stone’s throw away from sales. So far, it feels like sales is just the product development cycle minus the product development part—meaning all sales is is listening (a lot) and then connecting the existing product or service to the customer’s pain point.

The higher the contract value and the more consultative the sales or the younger the company, the more I’m sure the sales person gets to be creative with the solution or package offered to the end user. The guy who I’ve talked to selling seven figure gen AI contracts to Fortune 100 companies has a lot more flexibility with the offering than the person who tried selling me $10,000 a year accounting software. The more resources the sale will produce, the more resources you can spend on customizing it for the user.

Right now, being so early stage, even if the contract size is a fraction of seven figures, our sales cycle is much more like the Gen Ai guy’s cycle, but even a little more extreme—we’re quite consultative because we’re still building out the solution. Product development is sales for us and I think it’s preparing us for more scalable sales, too.

Service as a Software

I had a great conversation this weekend with someone using AI to help manufacturing companies in the US optimize their logistics and resource planning across the firm. By AI, though, he means Virtual Assistants (VA) in the Philippines as he actually builds out the software.

For us, there are some VA’s, but there’s also a lot of Jack and I manually delivering the solution while Adi and Mo are automating; it’s a bit more difficult to outsource when our feature set is still changing every week.

In other words, instead of the typical SaaS, or Software as a Service, some days it feels like we are doing Service as a Software, as my friend doing manufacturing ai so eloquently put it.

That being said, this makes the product development cycle more lightweight—when we hear something from a customer that they think they want, we can test it out by just doing it ourselves without spending so long engineering it and nearly immediately see what their feedback is. Do they actually want it, will they actually use it?

And then from there, a part of running a startup that’s probably just as critical as product development is resource allocation, and for us, a big part of asking that is asking which parts of the process do we invest in automating? This implies having a strong technical team that can actually figure out how to automate something and estimate its costs, but that discussion warrants another post entirely.

I was back in SF this week, and, as always, was reminded the value of 1) being physically near customers 2) having low cost to meet people who are smarter than you.

Still not sure where I will end up, but talent density is a big draw.

Live Deeply,