NOAH
JACOBS

TABLE OF CONTENTS
2025.02.09-On-Overengineering
2025.02.02-On-Autocomplete
2025.01.26-On-The-Automated-Turkey-Problem
2025.01.19-On-Success-Metrics
2025.01.12-On-Being-the-Best
2025.01.05-On-2024
2024.12.29-On-Dragons-and-Lizards
2024.12.22-On-Being-a-Contrarian
2024.12.15-On-Sticky-Rules
2024.12.08-On-Scarcity-&-Abundance
2024.12.01-On-BirdDog
2024.11.24-On-Focus
2024.11.17-On-The-Curse-of-Dimensionality
2024.11.10-On-Skill-as-Efficiency
2024.11.03-On-Efficiency
2024.10.27-On-Binary-Goals
2024.10.20-On-Commitment
2024.10.13-On-Rules-Vs-Intuition
2024.10.06-On-Binding-Constraints
2024.09.29-On-Restrictive-Rules
2024.09.22-On-Conflicting-Ideas
2024.09.15-On-Vectors
2024.09.08-On-Perfection
2024.09.01-On-Signal-Density
2024.08.25-On-Yapping
2024.08.18-On-Wax-and-Feather-Assumptions
2024.08.11-On-Going-All-In
2024.08.04-On-Abstraction
2024.07.28-On-Naming-a-Company
2024.07.21-On-Coding-in-Tongues
2024.07.14-On-Sufficient-Precision
2024.07.07-On-Rewriting
2024.06.30-On-Hacker-Houses
2024.06.23-On-Knowledge-Graphs
2024.06.16-On-Authority-and-Responsibility
2024.06.09-On-Personal-Websites
2024.06.02-On-Reducing-Complexity
2024.05.26-On-Design-as-Information
2024.05.19-On-UI-UX
2024.05.12-On-Exponential-Learning
2024.05.05-On-School
2024.04.28-On-Product-Development
2024.04.21-On-Communication
2024.04.14-On-Money-Tree-Farming
2024.04.07-On-Capital-Allocation
2024.03.31-On-Optimization
2024.03.24-On-Habit-Trackers
2024.03.17-On-Push-Notifications
2024.03.10-On-Being-Yourself
2024.03.03-On-Biking
2024.02.25-On-Descoping-Uncertainty
2024.02.18-On-Surfing
2024.02.11-On-Risk-Takers
2024.02.04-On-San-Francisco
2024.01.28-On-Big-Numbers
2024.01.21-On-Envy
2024.01.14-On-Value-vs-Price
2024.01.07-On-Running
2023.12.31-On-Thriving-&-Proactivity
2023.12.24-On-Surviving-&-Reactivity
2023.12.17-On-Sacrifices
2023.12.10-On-Suffering
2023.12.03-On-Constraints
2023.11.26-On-Fear-Hope-&-Patience
2023.11.19-On-Being-Light
2023.11.12-On-Hard-work-vs-Entitlement
2023.11.05-On-Cognitive-Dissonance
2023.10.29-On-Poetry
2023.10.22-On-Gut-Instinct
2023.10.15-On-Optionality
2023.10.08-On-Walking
2023.10.01-On-Exceeding-Expectations
2023.09.24-On-Iterative-Hypothesis-Testing
2023.09.17-On-Knowledge-&-Understanding
2023.09.10-On-Selfishness
2023.09.03-On-Friendship
2023.08.27-On-Craftsmanship
2023.08.20-On-Discipline-&-Deep-Work
2023.08.13-On-Community-Building
2023.08.05-On-Decentralized-Bottom-Up-Leadership
2023.07.29-On-Frame-Breaks
2023.07.22-On-Shared-Struggle
2023.07.16-On-Self-Similarity
2023.07.05-On-Experts
2023.07.02-The-Beginning

WRITING

"if you have to wait for it to roar out of you, then wait patiently."

- Charles Bukowski

Writing is one of my oldest skills; I started when I was very young, and have not stopped since. 

Age 13-16 - My first recorded journal entry was at 13 | Continued journaling, on and off.

Ages 17-18 - Started writing a bit more poetry, influenced heavily by Charles Bukwoski | Shockingly, some of my rather lewd poetry was featured at a county wide youth arts type event | Self published my first poetry book .

Age 19 - Self published another poetry book | Self published a short story collection with a narrative woven through it | Wrote a novel in one month; after considerable edits, it was long listed for the DCI Novel Prize, although that’s not that big of a deal, I think that contest was discontinued.

Age 20 - Published the GameStop book I mention on the investing page | Self published an original poetry collection that was dynamically generated based on reader preferences | Also created a collection of public domain poems with some friend’s and I’s mixed in, was also going to publish it with the dynamic generation, but never did.

Age 21 - Started writing letters to our hedge fund investors, see investing.

Age 22 - Started a weekly personal blog | Letters to company Investors, unpublished. 

Age 23 - Coming up on one year anniversary of consecutive weekly blog publications  | Letters to investors, unpublished.

You can use the table of contents to the left or click here to check out my blog posts.

Last Updated 2024.06.10

Join my weekly blog to learn about learning

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. 

Subscribe

-------------------

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.



Caption: The length of the line is equal to the time spent on an activity per one “iteration,” and the number of lines shows number of iterations; it makes more sense in the next pic.

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:



Caption: I present to you, the product development cycle in four iterations. (I’m not the first person to ever do product development, but maybe the first to make a graph that’s this difficult to understand.)

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:



Caption: More listening over all in one cycle, but slightly less to each individual user.

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.

Subscribe

-------------------

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,