settled on some ideas. built a few prototypes. onto a program!

Tbh I met some really cool investors through the last piece.

I do have a concise update I send to investors I truly love, mostly from my last company. If you’re interested DM me on Twitter (follow me so I get it) and lets find a time to chat :)

Today is a fun day – it’s exactly 3 months since I arrived back in SF.

I have a solid routine, an idea space I’m quite like, a great view of the maze and its various pits, and a few core beliefs that make me feel like I’m fighting for something.

Last time I told you how I think through coming up with ideas. People think it’s an art but it’s also a science.

This time I’ll tell you what I’ve prototyped for the last 6 weeks, and how I think through next stage – building a program.

So where did I land on ideation?

The goal of ideation is coming up with idea spaces that have business potential and that you are excited about.

You learn that idea’s “maze” and (imho the overlooked part) look inward to decide if this problem is what you want to dedicate yourself to solving for >5 years.

6 weeks ago I settled on two idea spaces after unpacking their detailed mazes.

To keep it high level, it was:

1. Enhancing developer productivity

2. Orchestrator agent that directs other vertical agents

They’re quite similar. However distinctly different mazes.

Now I’ll talk about how I went from idea space → prototype → prototype → prototype until I came out the other end. This is what I’ve been up to :)

high-level: prototype phase framing and some loser companies that skipped this step

The goal of prototyping is to come up with the single, major marquis use case.

Keywords: single, major.

Too many people say “my app is really cool, it helps you do all this shit, most of which you don’t really care about”.

The problem here is every not-so-useful feature dilutes the useful one. Users won’t know about the useful one, they’ll get distracted on the not useful ones. The story will be less coherent so you won’t reach the right folks. And that’s 1 year down the drain.

It’s like when you get a slide deck that has an amazing point buried in 15 slides of meh. You will fall asleep by the time you hit the good stuff. You’ll write it off as not worth your time.

Tons of companies miss this. Some turn it around. Ever heard of Burbn?

It had a bunch of shit. Location sharing, check-in at places. Making plans. Also a photo app section. Disaster right? What a lame app.

After 1 year they deleted everything except the photo part and re-branded.

18 months later it was acquired for 1 billion dollars. It’s called Instagram.

Justin.tv used to let anyone livestream anything. Mainly became copyrighted tv shows and sports games. After 5 years, it made ~$30K in profit a year. Horrible business.

Then they focused on video games and re-branded. You could already make it work for games, some did. But it was hard. Like 8 clicks buried behind a menu hard.

36 months later they were acquired for 1 billion dollars. It’s called Twitch.

The point is simple: you should find the one thing that’s amazing and hone in. Then everything falls into place.

Then the story attracts the right people, which means they get through onboarding, and give useful feedback for real adjacencies.

And by the way, Instagram now has location tagging. And Twitch has a sports game section. But they added it on after honing in, so their product was crafted correctly.

tactical: how does one get there?

It’s actually quite simple: each week, build an ugly hack prototype or mockup that will teach you something about your entry point into that single major use case. Show it to 1-3 people.

Repeat until you have conviction that there’s a single major use case. If you reach a dead end, start over.

By the way, this is the biggest misconception: “I will only build one prototype. It must be perfect and have everything”.

Please. I beg of you. Don’t make that mistake. Lower the bar to prototype :)

You are designing an experiment to learn your solution. For example, there’s someone non-technical I met who has a whole strategy that will maybe get him an engineer in order to maybe get an investor in order to maybe build a prototype for a problem that he’s assuming is really intense but has doubts about. This is very common.

What a waste of time.

Instead you should be like Helena Merk, my housemate for 3 years, a YC W20 batch mate, and one of the most formidable founders I have ever met.

She’s insanely technical. Yet she got into YC using a spreadsheet and Google forms to build an “app” where she matched people for professional networking. This was a prototype. She made many changes. Learned a bunch. Knew what to build and where Lunchclub fell short.

That became Glimpse, later acquired by twine.

The second often overlooked part is teach you something. Asking the right questions matters if you want a non-trivial answer. This is hard.

I probably spend a few hours each week deciding just what question I want to answer and course correct to make it more precise once more each week.

A rule of thumb: don’t ask trivial questions. If you can truly guess the answer, then you probably don’t have the right question.

back to me: so “what did you do last week” (x6)

I chose “orchestrator agent that directs other vertical agents”. There are a few reasons I’ll bring up in Part II given bleeding edge emergent behavior. I’m starting with developers. But those reasons brought me to this starting point:

A Mac app that passively collects context. When you type in \ into a AI app input, it will enhance your prompt with more context.

Week 1-2.

• Question: Is auto-improving your prompt an intense enough problem?

• Answer: (I didn’t get one. It slowed down their computer until it froze. oops.)

Week 3. Fixed.

• Question: same

• Answer: Unsure. Speed needs to be under 2s, we’re at ~10 - 15s. They want to know what context was used to trust it.

Week 4: Speed solved. Mockup passes test.

• Question: Will they consistently use this?

• Answer: No. About 4-8 times in they just manually edit. They want to guide the improvement.

Week 5 - 6: Added the ability to set the prompt per application. Added the ability to do “\make it more concise\” to guide the improvements.

• Question: same

• Answer: Yes for most! Some cases need local filesystem access. Some cases need to understand higher level intent rather than adding specifics. Some cases they only want to select specific text to modify it.

Bingo. Conviction on this major single use case reached.

So at current, it’s a Mac app that passively collects information. In any text area, you click “\”, type how you want to adjust the text, then click “\” it will transform your text.

Eventually we will be able to proactively surface complex actions that you can remotely execute.

So what am I building? Just Another, Rather Very Intelligent, System.

Or in short, JARVIS :)