I’m trying to tweak the layout, David is tweaking the content, and Ben is trying to add a new new page.

Then Webflow kicked me out.

Why? Because we were trying to edit the site at the same time.

That was the moment we realised: this tool was slowing us down.

At Superthread, we’re a small team of three. We move fast. We iterate constantly. But Webflow’s single-user editing model became a silent tax on speed.

We’d used Webflow for two years. It had served us well, but it was now obvious it was reducing our velocity. So we’ve bit the bullet and moved our entire marketing site from Webflow to Framer.

Why we switched

This wasn’t just a redesign. It was a full rebuild. And it came with some wins – and some real tradeoffs.

Our goals were pretty simple:

• Make the site feel more modern and polished

• Move faster as a team

• Collaborate in real-time without stepping on each other

• Avoid engineering bottlenecks for simple design tweaks

Webflow’s biggest flaw for us was single-user editing. One person at a time. No exceptions. In 2025, that feels broken – especially when we collaborate in real-time in Figma, Slack, Google Docs… even Superthread itself.

Real-time collaboration matters

When we first opened Framer, the experience felt instantly familiar – like Figma, but with a publishing button (that said Figma now has site building feature in beta).

We were editing different pages at once, seeing each other’s cursors, leaving comments, and building components together. Just like that, our bottlenecks disappeared.

It wasn’t just faster – it was more fun.

Framer feels purpose-built for small product teams who want to move fast without writing a ton of code. The component system is clean and intuitive. Adding basic animations, fades, transitions, hovers is almost magical. You design the states you want, hit Publish, and Framer turns them into real, performant front-end code. It’s surprisingly empowering.

Where Framer falls short (and some workarounds)

To be clear, the move wasn’t frictionless. Framer came up short for us in a few small ways, but we’ve been able to work around most of them.

1. Image loading optimisation

We care a lot about performance. With Webflow, we could control lazy loading, preloading, compression, image formats – the whole deal.

In Framer, we hit a problem with tabbed screenshots: when you clicked a tab, the image would load on demand, causing a jarring flicker. In Webflow, we could set these images to preload so they’d appear instantly when a user clicked between tabs.

Our hacky workaround: load all images upfront and toggle their opacity when a user clicks into a new tab. It worked – but it’s not elegant. This is both a testament to how easy it is to configure interactive components, but also frustrating that a workaround was needed in the first place.

It’d be great if Framer had built-in options to manage preload strategies or smarter lazy-loading behaviour.

2. CMS design

Webflow’s CMS, while not perfect, is fairly powerful. It supports reference fields, dynamic filtering, multi-reference relationships, and more. Framer’s CMS is still quite basic by comparison. For our current needs, it’s fine. But if we were running a more content-heavy site with dozens of blog posts or SEO landing pages with structured data, we’d probably hit some limitations. Considering Framer emphases its design prowess, its disappointing that you cannot create components to customise the way images are displayed, or create galleries within the CMS.

3. Text truncation (or lack thereof)

This one’s silly, but painful.

You can’t truncate text properly in Framer. No text-overflow: ellipsis. No line clamping. Nothing.

So if you’re building a blog index or a grid of cards, you’ll either:

a) cut the text off mid-word
b) end up with uneven layout heights
c) scream

Our workaround? Set container heights to an exact multiple of line-height so at least it doesn’t chop the text horizontally. Not ideal.

We could write custom CSS where we absolutely need truncation, but that defeats the whole low-code goal of the platform.

4. No way to re-use layout styles

This one hurts the most.

In Webflow, you can create a layout class (say, section-spacing) and reuse it across every page. Update it once, and every instance updates.

In Framer, there’s no way to define global layout styles. Want to change the vertical spacing between sections across 30+ pages? You’re doing it by hand. Double that if you want different spacing on mobile.

This is a big reason why small layout tweaks feel heavy in Framer.

I don’t know an obvious workaround – please let me know if you find one! Webflow is much further ahead here, especially as it allows you to create compound styles by stacking multiple classes on the same element.

Summary of tradeoffs we’ve experienced

Heres a quick summary:

Why we’re still glad we switched

Despite those limitations, the move to Framer has been a net positive.

• We can move faster as a team – no more design session lockouts.

• The design experience is better – font styles and breakpoints are super easy to work with, and the interface is fast and snappy.

• We enjoy using Framer – its fast, intuitively laid out and rarely gets in your way.

• We’ve added animations and interactive polish to our site without needing engineers.

• The component system helps keep our design consistent across new landing pages.

• The community copy/paste remix system is a delightfully simple way to experiment with new ideas.

• The recently added support for vector assets and creation is extremely welcome.

• It’s just plain easier to collaborate in real time.

Framer might not be the right tool for every team, especially if you need deep CMS functionality or full control over performance optimisations. But for a small team that needs to move quickly and work together without friction, it’s a game-changer.

Final thoughts

We’re not blind to Framer’s limitations and I’m sure we’ll discover more. No tool is perfect. Webflow gave us power – but slowed us down. Framer gives us speed – but hides a lot under the hood.

We chose velocity.

It’s the right trade-off for our team right now.

It’s not.

Chatbots exploded because they were the fastest way to showcase raw model power. You could ask anything, get a fluent response, and feel the magic instantly. But as we settle into the reality of AI at work, the cracks are starting to show, especially when chat becomes the only way to interact with intelligence.

The real challenge? Pure chat struggles with structure, speed, and signal clarity — three things your brain craves when dealing with complex workflows. Whether you’re managing a roadmap, chasing dependencies, or skimming notes from a meeting, reading a block of text from a chatbot just doesn’t cut it.

Apple’s own research sets the tone

Apple’s updated Foundation Models paper explains that the on-device 3-billion-parameter model “excels at summarisation, entity extraction, text understanding, refinement, short dialogue, generating creative content, and more. It is not designed to be a chatbot for general world knowledge.”

The message is clear. Apple wants intelligence to surface inside existing views instead of sitting in a separate conversation window.

Intelligence belongs inside the interface you already use

In the press release that introduced Apple Intelligence, Apple highlighted that the system is “deeply integrated into iOS 18, iPadOS 18 and macOS Sequoia”, where it draws on personal context and takes action across apps. There is no mention of a new standalone chat app; the primary interface stays visual and interactive while AI fills in the gaps.

Why pure chat still struggles in everyday work

• Linear scroll versus spatial clarity – A roadmap or dashboard lets you gauge status at a glance, whereas a chat log forces you to hunt for information.

• Open-plan etiquette – I am a big voice fan, yet in offices most people type because speaking aloud feels intrusive and reveals private queries.

• Cognitive load – A single prompt can return a dense block of prose. A visual layer can show the same insight with coloured badges, small sparklines or hover cards that you scan in seconds.

What comes next?

Probably AI-first glanceability

No-one has the final pattern yet. My sense is that interfaces will stay quick, clean and click-friendly, with AI quietly filling in details when you need them. Think of timelines that auto-flag silent blockers or boards that highlight at-risk work without waiting for you to ask. The specifics will evolve; contextual augmentation is likely to stay.

Voice still shines, just not everywhere

Voice transcription coupled with AI-generated notes is close to magic when you are capturing meetings. Inside Superthread I record, transcribe and let the model summarise calls; the note then appears in the timeline where I can see how it fits with everything else. Apple’s own Notes and Phone apps support the same flow: record, receive a transcript and view an instant summary in place.

Yet once I am back at my desk I prefer to skim those summaries rather than listen to a bot read them aloud.

The takeaway

Chat is brilliant for open-ended ideation and hands-free moments. Dense, state-heavy tasks such as project management require something different.

Chat for capture; GUI for clarity; AI as the invisible glue.

Fast, AI-augmented interfaces — Superthread included — are more likely to shape the next wave of productivity than one-size-fits-all chat windows. The coming UX leap will not sound like a conversation; it will look like the dashboards you already trust, only sharper, lighter and far smarter.

You’ve done all the hard work of talking to people and gathering data. Now you need to surface these learning and turn them into actionable insights!

In this post, we’ll cover how to do just that. 💪

Welcome to part 4 of my PMF sprint playbook series! Make sure to catch up on the previous posts 👀

Part 1: How to run effective PMF sprints

Part 2: How to get people to talk to you about your ideas

Part 3: How to extract unbiased insights from customer calls

Surfacing the signal

We’ve already briefly discussed how to structure and format your customer calls to optimise for unbiased information. The ultimate goal and why you started this whole process in the first place still hasn’t changed. You have to:

Hopefully if you’ve done your customer calls right, you will have gathered valuable data and can extract these jobs to be done or unmet needs from each one. LLMs are obviously great at this, but really try to distill the core learning from each call into a couple of sentences. For recruitment agencies this could be, for example:

Clients want visibility into recruitment progress but in manageable formats

Retained jobs often come with detailed market maps using Excel spreadsheets shared with clients. This results in duplicated work and takes 1h on average to complete.

In the cases where no obvious themes or clustering emerge you can drill down further by putting this data into a priority matrix using your preferred white-boarding tool. Here’s one we did for project management:

The idea here is to help you rank, identify and prioritise the interesting problems surrounding your hypothesis. This is not an exact science and you will need to mix your intuition with past experience and memory from previous conversations. Hopefully you will have gathered strong data on whether or not these needs are important during your interviews.

You’ll walk away from this process with either:

1. Confirmation that your initial hypothesis was spot-on

2. Discover adjacent problems with greater opportunities for growth

In both cases you’ll want to dig deeper and feed this learning back into your product roadmap or into your list of growth experiments for your next PMF sprint.

Start with the end

The best way to start thinking about the next steps on any of these ideas is to define expected results. This is the hardest part of the planning, but it will help you clearly define the success criteria for when to commit or move on. It will also cement the potential impact on your goal. In our case, it also flagged areas where we weren’t tracking or surfacing the right data from our product analytics.

You’ll also want to try and quantify your intuition and hunch that this will work. It’ll help you prioritise and decide which ideas to tackle first.

Sean Ellis, author of “Hacking Growth”, codified this process into the ICE framework. The main idea is to list these hypotheses and score them according to 3 criteria:

1. Impact: “If successful, how big will the impact be on our goal?”

2. Confidence: “How sure are you that this will work?”

3. Ease: “How easy is this to implement?”

Here are a few examples of what this could look like in a fictional scenario:

I added a results date to measure the “time to impact” to also optimise for fast feedback loops.

What is missing from this sheet is the methodology on how you will actually execute and move the needle. In some cases this is obvious, however when writing these down, you need to consider what is the minimum viable experiment that will give you evidence of positive results.

The key is to break down potentially high effort experiments on a hypothesis into the smallest possible effort. Iterate as much as you can on this to ideally get the ‘Ease’ above 5, whilst understanding that this will obviously have a lesser impact or dilute your expected results.

A classic example of this is the fake door test where you can present an option to an end user before you implement anything to track engagement. Read this pricing experiment from a growth engineer at Masterclass for a more concrete example of this.

Another idea that we’ve been playing around with is to change the ‘Expected results’ into a ‘Kill criteria’, for example:

< 25 % adoption after 7 days ➜ kill

Lean learning loop

Your PMF journey lives and dies by how fast you can learn and experiment before you run out of money. Create hypotheses, distil raw signal and deploy it into the next experiment. Keep the loop tight and the rituals light.

Everything else is just noise.

I’ve seen many founders speak — often from companies far larger — but most of the time, their advice feels detached. They share lessons polished by time, packaged into neat frameworks that sound good on stage. It’s rare that you hear something raw.

This talk was different.

Despite everything they’ve achieved — 10x growth, massive revenue, global footprint — the founder was genuinely humble. What struck me most was how familiar his current reality sounded. He’s still doing founder-led sales. He’s still personally picking up the phone, trying to close 100-seat deals. And often, it still goes nowhere. Just a few days before the talk, he’d pitched a prospect who quickly dismissed him: “We don’t need this.”

The key insight for me: the friction doesn’t really go away.

At $10B or at our size, you’re still facing the same uphill battle. The same skepticism from buyers. The same need to explain why this matters. The same rejection.

The founder’s advice was simple: you just have to keep going.

No shortcuts. No magic unlock. Just the grind — at every stage.

For me, hearing that was both grounding and motivating. It’s easy to assume that once you cross some threshold — $10M, $100M, $1B — things start to click into place and sales get easier. But in reality, it’s often just more of the same. Bigger numbers, same friction.

It was one of the most honest and refreshing conversations I’ve had in SaaS. And a useful reminder that the struggle isn’t a sign you’re doing it wrong — it’s just the nature of building something that matters.

You’ve managed to get on a call with a potential ideal customer. The hard part is over; now you get to have an interesting conversation with them, trying to uncover the hard truth about their context and motivations.

Nothing feels worse than realising you’ve spent days or weeks building something no one will use or value. Today, I’ll show you how I try to uncover the truth behind every customer conversation.

In case you missed my previous posts, this is part 3 of my PMF sprint playbook. Don’t miss out on previous topics below:

Part 1: How to run effective PMF sprints

Part 2: How to get people to talk to you about your ideas

How to f*** it up

It’s surprisingly easy to do. We’ve all done it. That’s how we end up wasting time working on the wrong thing, or worse, “validating” tarpit startup ideas.

Here are some bad questions and why:

• Solution-first questions: “Would you use my idea?” → Courtesy yeses.

• Hypotheticals: “How much would you pay?” → Fantasy pricing.

• Leading phrasing: “Do you have a problem with…?” → Interviewer bias.

The most common pitfall is to fall into pitch mode and start talking about your idea or solution. The goal of these calls is to learn, not sell. Most of the time, however, I’ve found that the interviewee will want more context and start asking you probing questions. Counterintuitively, I usually found that providing some context up-front can prevent them from wondering what this is about and focus the conversation on them, not on you. For example:

I’ve seen [persona] having some success with [problem] using our product. I’m curious to see if this will resonate with you. Can you show me, step-by-step, how you currently do [job to be done]?

Asking good questions

First of all, what are good questions? Let’s look at the examples from earlier.

• “Would you use my idea?” → “When is the last time you tried to solve [problem]?”

• “How much would you pay?” → “How much time (or money) did you spend on this?”

• “Do you have a problem with…?” → “What was frustrating about that process?”

Notice that these are anchored in the past, which is real, tangible data that they can’t fake or go back and change. Steer clear of opinions and focus on getting them to tell you stories.

I’m not going to sit here and pretend that this is easy, and I do this perfectly. Honestly, most people won’t think that what they’re doing is wrong or can be improved. This usually means that starting with a generic opening asking about the pain or frustration won’t work. Don’t do this:

Hey, nice to meet you. […]. What’s the most frustrating part about [job to be done]?

A real example of this happened to me recently when an ICP described an incredibly manual process in Notion. She was spending probably a couple of hours a day on something that another tool could do in minutes. My immediate reaction was “wow, this sounds like a lot of admin”. She agreed, but said the perceived value they were getting out of good-looking Notion documents was worth it. Seeing an opportunity, I followed up with:

“When was the last time you tried to change or review the process?”

She then finally admitted that they could be more efficient, and this wasn’t ideal, but they haven’t done anything about it. I asked more questions related to why they decided to use Notion in the first place and who made the decision. I quickly realised she was championing the tool and process internally herself, and it didn’t seem like a burning issue, so I moved on. Looking back, I made a huge mistake. I could have drilled down even further by asking questions like:

• “Has anyone in your team complained about this?”

• “If you could do this in 5 minutes per day or not at all, what would you choose to focus on instead?”

• “What would be the impact on your output?”

3-step unbiased flow (PIT)

I’ve tried to keep my process in these calls very simple to let the conversation flow: beginning, middle and end. As I mentioned in Part 1, being too prepared and rigid can really kill the buzz and honest exchange you have with someone. I usually try to stay open, sincere and show some empathy whenever they describe a pain point in their workflow.

We’ve already discussed the opening and closing statements at length, so let’s focus on the most important bit: the middle. I’ve come up with a quick acronym to codify and remember this: Process, Impact, Timeline (PIT)

Process

“Show me how you …” — screen share if possible, to uncover the real workflow.

Impact

“Where did you spend the most time?”

“What would be the impact on your work if you could easily do this in 5 minutes or not at all?”

Try to let the emotions and frustrations come out naturally at first, and if they don’t, you can always follow up with:

“What was the most frustrating part?”

Here, the goal is to uncover and quantify pain points they care about.

Timeline

“When did you last do this?” — anchor details in a concrete past event and timeline.

“How often does this happen?” — separate chronic pain from edge cases

Bringing it all together

I’ll leave you with a quick summary cheat-sheet that you can download, re-use and study in between calls

Remember to transcribe, take notes and share takeaways with your team! If you do these right, you’ll walk away with a ton of valuable insights.

Hit subscribe so you don’t miss the next “build-or-kill” post! 👋

Subscribe now

Today we’ll tackle the toughest step: getting busy prospects to say “yes” to a 15-minute call so you can validate, or kill, your hypothesis fast.

Below is a proven 5-step outreach ‘playbook’ that should enable you to have at least 10 conversations per week.

Reaching out

This is the hardest part. You’ll want to start this as soon as you have a rough idea of the persona in your hypothesis as it will take a while to get your first responses and start getting some time booked in your diary. Do this first and then in parallel to everything else.

If I could give my younger self a single piece of advice it would be:

Go to meet-ups, conferences. Be curious. Be kind. Make meaningful connections. Keep in touch. Start doing this as early as possible in your career and never stop. If you do this right you’ll end up with a high quality network of people that will help you in more ways than you can imagine, including talking to you about your ideas.

🌐 Step 1: Your own network

This is the simplest and most obvious. If you’re lucky or you’re building something you and your friends might use then it should be pretty easy to reach out to them and ask them for 15 minutes of their time.

You can also put out a post on LinkedIn or target specific people you’ve met in the past or go around your co-working space and offer to buy them a coffee.

The message doesn’t need to be sophisticated at this point. Here’s a simple 2-line DM:

Hey {Name}! I’m exploring a problem many [persona]s face. Free for a quick 15-min chat next week? No pitch, just research. Coffee’s on me ☕

Track every message you send. Momentum is a metric. On top of that, if your co-founders ask you what you’ve been doing all day then you have a clear answer.

📣 Step 2: Your network’s network

This is probably the most effective way of getting the ball rolling. You might not know anyone in your own network that fits the persona you’re looking for but it is extremely likely that someone you know can introduce you to one.

You’ve probably already done the obvious and asked your investors or colleagues but have you really tapped into the full potential of your network? Think about your extended family (distant cousins), everyone you’ve ever worked with, people you met at a party, etc…

If you remember anything from this post, it should be that the best thing you can do to get more conversations scheduled is to ask each participant to make introductions for you. Think of it like a flywheel: getting the first few calls is hard but once you have a couple the introductions will compound and next thing you know you will have spoken to 20 different people in under 2 weeks about your idea.

I generally close conversations with the following simple questions:

1. What haven’t we discussed that you think is worth mentioning?

2. Can you introduce me to anyone that you think would be relevant to [persona] or [problem]?

The first question gives the person a chance to bring up something that you might not have thought of asking or focusing on. What they say will give you an inkling into what they think is important or care about. Lenny is an excellent interviewer and if you listen to his podcasts, you’ll notice he always asks this question.

The main lesson I’ve learnt here is that 90% of people are generous and willing to help you given that you have some connection to them.

The best thing to do is to get the person who has the strong connection to do the introductions and take it from there. If that’s not possible, I’ve found that a heartfelt and honest message with a sprinkle of flattery and vulnerability works best.

Hey [name], [mutual friend] spoke very highly of you and recommended I get in touch. I don’t know much about [X] and I was hoping you could give me 15 minutes of your time so I can pick your brain on the topic. Not trying to sell you anything, just looking for a casual chat :)

In all of your outbound messaging it’s important to emphasise that the reason you’re reaching out is not to try to sell them something or ask them something that would make them uncomfortable, e.g. poaching clients or stealing information.

3. 💬 Communities, forums and social

Hopefully you’re already part of some founder communities or social groups. These can be a bit noisy, so not a huge amount of people pay attention to them but you can put out a short post and you might get lucky. Reddit can work too but I’ve personally not had a huge amount of success connecting with people on there.

The thing I’ve found works best is to create an opinion poll or ask for help on a topic related to what your problem is or what your persona cares about. Go for something trendy or a contrarian opinion as those are the ones that get the most engagement. For example, a friend of mine recently put out a post entitled: AI killed the AI engineer, AI engineering is dead…

Here another example of a poll I ran in various CTO and dev communities to get introduced to product engineers.

Once you get some responses, reach out to each individual to thank them for participating and either: ask if they are up for a casual chat on the topic, or if they can introduce you to anyone that fits your persona.

4. 🤝 Go where they hang out

This is another tactic I’ve found useful and had success with. Your persona is likely to spend time somewhere in the internet digesting content relevant to their industry or somewhere physically networking with their peers. I’ve put this second to last because it’s the most involved and might not yield any tangible results in a reasonable amount of time.

This goes back to an earlier point I made: the best place to organically meet people and make genuine connections are at meet-ups and conferences. Find the ones your personas go to and go there yourself. I personally found this one quite difficult because I’m an introvert and I used to struggle to strike up a conversation with total strangers, but like most things: the more you do it the better you get.

Find out what content they consume and where. Hopefully you will have already scheduled a few calls and you can do this by making it one of your closing remarks:

• What newsletters do you subscribe to?

• What podcasts do you listen to?

• Who do you follow on socials?

• What associations, clubs, or meet-ups do you attend?

• What online communities are you a part of?

• What conferences do you go to?

• When you need to network with other [your-titles], what do you do?

Perhaps it’s a newsletter or an influencer. Reach out to them for intros, they might indulge you and connect you with a few people directly. Worst case scenario you will have also found out what channels will be worth putting some marketing spend behind if you start getting some traction.

5. 🥶 Cold outbound (when all else fails)

The name says it all, use sales tool such as Apollo or LinkedIn Sales Navigator to send outbounds to your ideal persona. Crafting a short, casual, solid message is key here to get some responses. Remember to compliment and show vulnerability. You can give some brief context by selling a vision as long as you keep it vague:

I’m trying to make desk & office rental less of a pain for new businesses.

Expect around 1 response out of 100.

Subscribe now

Common pitfalls

Avoid the following mistakes. Trust me.

Asking for a lot of time

You need to put the bar so low that they can’t think of any objections. 30 or 60 minutes sounds like a lot of time to dedicate even though, in practice, a lot of conversations I’ve had lasted this long despite agreeing to a much shorter timeline.

Along the same vein, offer to meet in person and go to their office to make it completely frictionless.

Fake premise

I’ve not done this myself but I have heard that it can work. You might be tempted to lie or embellish the reason you’re reaching out, for example:

I’m writing a book on [X], would I be able to interview you for market research

You will probably get better responses but in my experience this usually backfires unless you are actually doing what you said since, as with all lies (however innocent), you are digging yourself into a corner and it will be difficult to climb out of it to get genuine learnings. It could end up restricting the questions you want to ask or steer the conversation in the wrong direction.

Forgetting the flywheel

This is actually probably the most common one I’ve seen time and again.

Always close with:

Who else should I talk to?

Final thoughts

Let’s do a quick recap of the most important things you will have learned from this post:

• Get into the habit of meeting new people and growing your network

• Get to know investors or very experienced mentors if you can - they have amazing networks

• Be genuine and honest about why you’re reaching out - otherwise you’ll have a hard time getting valuable insights

Your goal is to have at least 2 conversations a day so aim for 20 in 2 weeks.

In the next post we’ll cover interview frameworks that separate signal from noise. Subscribe below so it lands in your inbox first.

Good luck out there!

I’ll break down what we found to work best when trying to figure out whether a specific problem is worth trying to solve. There’s a lot to talk about so I broke this down into multiple parts. Today, in part 1, I’ll discuss all of the preliminary work and give you a basic structure so you can maximise learnings.

Why a PMF Sprint?

A PMF sprint is a a 2/3 week, interview-heavy block of time solely for testing a problem-market hypothesis.

Like most things in life, you’ll get better results if you exclusively focus on a specific problem. That’s the idea behind the ‘sprint’. Dedicate at least 2 weeks of your and possibly another founder’s time on this one specific thing. Don’t get distracted. Stop everything else. Commit everything to this and treat it like a sprint, not the usual product building marathon.

The Secret Sauce

The first step is to have a concrete idea of what it is you want to validate.

How do you form a solid hypothesis of a problem to solve?

Todd Jackson from First Round Capital breaks this down into 3 approaches

1. Market first: Start with a market or space that interests you, then look for a specific problem.

2. Experience ripe for improvement: Look for areas where you believe there should be a better consumer experience than what currently exists, and iterate from there.

3. Problem first: Start with a problem you’ve experienced firsthand and figure out if enough other people have the same problem.

There are loads of examples of successful founders that have done this. I won’t go into detail here. Quickly you’ll start to realise that your ability to talk to people and extract the right information is the most important skill you’ll need to develop at this stage.

4 Ps in a Pod

To begin with you should already have thought about or heard of a specific pain point and thus identified the first P: the Problem.

Next, before we can actually go out and start talking to people we need to narrow down who most commonly faces this problem: the Persona.

You don’t need to do these in this specific order. You might have started with a market-first approach in which case you’ll have figured out your Persona before the Problem. Once you combine those two you’ll have some sort of idea of what it is you can solve. That’s the Promise.

Finally to deliver on this Promise you’ll end up with the Product. Notice that what you are building is the last step and the culmination of everything else in your strategy. The product comes last. It merely crystallises the problem, persona and promise you’ve already nailed, which is the core idea behind sustainable PMF growth.

A solid hypothesis is very simply a document. Something that articulates an offering based on those principles.

Don’t spend a huge amount of time on this. At most half a day thinking deeply about it and writing the document and getting feedback from peers.

I sometimes like to add a fifth P to frame it considering existing products you might be competing with: Positioning. For example:

Unlike [competitor product], our offering [differentiator]

Script

Now that you have a better idea of who to target and why, you can start coming up with the right questions. Here we’re starting to enter the realm of how to develop the skill of talking to potential customers.

Rob Fitzpatrick wrote essential reading on this: The Mom Test.

After reading this book I made the classic mistake of trying to structure the perfect interview script with lots of great unbiased questions I could ask. As a software engineer by trade I have a habit of going deep with structured thinking. This was mostly a waste of time. You’ll never get through those questions like you would in an interview since you want to keep things as casual as possible to get people to open up and stay engaged in the conversation. I still got value from doing this however since I ended up diving really deep into the persona and hypothesis, but it’s definitely not necessary.

The key is to boil it down to 3 questions that will make or break your hypothesis. These should be elephant in the room, ‘scary’ questions that will help you focus in on the critical information you want to get out of these conversations once you’re in the thick of it. Having a limited number also makes these easy to remember and simple to casually introduce into the conversation.

AI will do a pretty good job of helping you here. You can paste your hypothesis doc and any additional context with the following example prompt:

Based on the following hypothesis what would be your top 3 questions to other potential [persona] to validate whether they would pay for solving [problem]. These should be “elephant in the room”, scary questions that will make or break the hypothesis. Avoid obvious opinionated questions. Use “The Mom Test” book as a reference for good questions to ask.

Notes

The final piece of preparation you’ll want to do before you start jumping on to calls or talking to people is what you’ll do after these calls. The idea behind all of these initial steps is to lay solid ground work beforehand so once the calls start coming in you can solely focus on those and getting more in the pipeline since that’s the bulk of the work.

The best argument for taking notes is so that you can share the learnings with your team. It’s the best way to get everyone aligned and on the same page. The other argument is that, in this day and age, it’s dead simple to transcribe a call, put it into an LLM and get it to come up with a great summary takeaway. Even if you’re having a casual conversation you can record yourself talking through the key points after the discussion and get a similar outcome.

Luckily for us we also have that built-in to our product. You can start a new note, transcribe and still write down any critical information you want to during the call.

The only thing you’ll actually need to prepare here is a solid prompt for getting a consistent output. What we found works best is to start with direct quotes and then have sections based on factual information surrounding your hypothesis. In Superthread you can create templates that will automatically format your notes after your call in this way and this saves me a huge amount of time but any other tool will work as long as you can pull the transcript of the call and paste in your prompt into your favourite LLM model of the day.

If you’re a solo founder without a team or if you’re super early in your journey you probably wouldn’t need to actually do this. As long as you trust yourself and your brain not to forget the actual learnings or care about leaving a paper trail and having something to come back to.

Next steps

That’s your prep completed. You can get all of this done in under a day’s work and you’ll have a really solid foundation for what comes next: scheduling and talking to people. We’ll cover those in the next post. Stay tuned!

Go draft your one-page hypothesis doc, block 2 weeks in your calendar and reply or comment ‘PMF’ to this if you want to receive my templates.

Subscribe now

📊 Out of 36 responses:

• ✅ 11 said “Yes – it works really well”

• 🤔 20 said they had mixed results

• ❌ 3 said “No – it hasn’t worked for us”

• 🤷 2 said “They hadn’t tried or considered it”

Given the perceived rise of product engineering roles, I was surprised by the amount of mixed results and had predicted more success. I dug deeper given the limited sample size and had some excellent conversations with CTOs and product engineers. Here are the takeaways.

🧩 Success depends on culture

Many leaders expect engineers to think in outcomes, not just implementation

“The best systems are engineered from a great understanding of the customer problem.”

— but in reality what they actually work on is still being fed to them in a top-down hierarchal manner.

Whether it works depends heavily on how aligned leadership, incentives, and autonomy really are.

For example, one product engineer described a culture of low process, high independence, and deep technical work—but still felt frustrated by leadership misalignment:

“We’re sometimes told to work on what we feel is not the highest impact business opportunities. It’s hard to redirect leadership.”

⚖️ The role only works if engineers want it

This is kind of a no-brainer but arguably remains to be implemented into your existing hiring process as a product competency section.

“We don’t hire unless engineers show clear motivation for product outcomes.”

You can do this by asking open-ended questions such as

• What gets you out of bed in the morning?

• What makes you feel like it’s been a good day?

• What gives you a sense of achievement?

You can then see if they include the customer or business outcomes in their answers.

But it doesn’t work for everyone. Not every engineer wants to operate this way, and trying to force it can create more confusion than clarity.

“Success is varied when I have tried to implement this within existing teams.”

⚠️ Product Engineers ≠ Magic Fix

Several engineers expressed a desire for tighter feedback loops with users—often bypassing PMs entirely.

“Product managers are like a broken phone line. I’d rather talk to customers directly.”

— but this model can fail if there’s no support structure, unclear product direction, or a mismatch in motivation.

“It’s rare that it works well. Engineers often jump to solutions instead of understanding the problem.”

Rather than eliminating product roles, some teams are finding success by having PMs mentor engineers into product-minded contributors — for example:

• getting them involved in product updates

• telling a customer their issue was fixed

• shadow you in customer call

So where does this leave us?

It seems like the Product Engineer is not a formal title everywhere, but it is a mindset that many teams are either hiring for, growing into, or aware of. The teams that have embraced it fully have observed successful outcomes.

As AI accelerates and the mechanics of software delivery become increasingly commoditised, the value of engineers who can think in bets, not just specs is only going up. The “Product Engineer” might not be standard today, but it’s likely a glimpse of where things are headed.

But here's the hard truth: most of this noise isn't critical to your immediate success. It can lead to analysis paralysis, distracting you from the vital work of building your product and serving your users.

One might even suspect that this constant barrage, this overwhelming noise, inadvertently (or perhaps intentionally?) makes it harder for smaller startups to gain visibility. The giants' narratives dominate, potentially overshadowing your innovative work.

Your Focus Must Be Internal:

• Define your core goals.

• Curate your news sources.

• Schedule limited news review time.

• Ground decisions in first principles.

• Prioritize user feedback.

• BUILD and ITERATE relentlessly.

Stop chasing every headline. Intentional ignorance is a superpower. Focus on your vision, build relentlessly, and let your product speak louder than the digital deluge.

It’s exhausting. It messes with your confidence. And it never really ends.

But a few months ago, I had a break from that. We needed an iOS app for Superthread’s new transcription feature. The main team was tied up, so I decided to build it myself.

For once, the brief was clear:

→ Capture audio.

→ Transcribe it locally.

→ Sync it into Superthread.

That was it. No questions about ICPs, no strategic forks, no existential ambiguity. Just: here’s what we need. Go make it.

And it was… peaceful.

Coding again after a few years away should’ve been painful. It wasn’t. I moved fast. Everything worked. When bugs appeared, I fixed them. When Apple approved the app, I grinned like I used to years ago.

This was a different kind of work — execution, not exploration. And I’d forgotten how good that feels.

When you’re in founder mode, every decision feels like it might kill the company. When you’re in builder mode, the world shrinks. The goal is in focus. You just move.

Founding is long-term painful with uncertain payoff. Execution is short-term tiring but deeply satisfying. You need both, but they’re polar opposites. I didn’t reali

se how burned out I was from constant ambiguity until I got to work on something with none.

If you’re a founder in the thick of it, try to carve out a small win like this. Build something bounded. Deliver it. Remind yourself you can still do things end to end.

It won’t solve everything. But it helps — more than I expected.

Building something people truly want—something that solves a real, painful, “hair-on-fire” problem—is one of the hardest things you can do.
They call it 'finding product-market fit.' I call it the most emotionally turbulent rollercoaster you can strap yourself into. The highs are incredible. The lows are brutal. Most days, you're somewhere in between—uncertain, hopeful, frustrated, stubbornly trying again.
This journey is not for everyone. You have to be a particular kind of person to enjoy this chaos. And even then, it tests you. Every day, you ask yourself: Is this working? Are we close? Am I fooling myself?
One of my heroes, Andrew Wiles, once described the process of doing mathematics like this:
“Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. You go into the first room and it's dark, completely dark. You stumble around, bumping into the furniture. Gradually, you learn where each piece of furniture is. And finally, after six months or so, you find the light switch and turn it on. Suddenly, it's all illuminated and you can see exactly where you were. Then you enter the next dark room…”

That’s exactly what it feels like to build a startup. Each room is a new problem space. Every feature, workflow, or customer segment is another bump in the dark. But sometimes—rarely—you flip the switch. And in that moment, everything makes sense.

At Superthread, today felt like one of those moments. We turned on the light in a big room and it manifested it self in a customer saying, “Shut up and take my money.” and using expletives to describe how good Superthread is.
There’s still a long way to go, and many more rooms to explore. But days like today remind me why we do this.
Because when you finally see it all lit up—damn, it’s beautiful.

Yet, as we've built and iterated on Superthread, we've learned something unexpected. The ideal project management tool isn't just a 'better Jira.' In fact, we've realised the best project management tool might just be the one you don't have to use at all.

PM tools benefit the org, not the individual

Project management tools, in theory, exist to provide clarity, align priorities, and ensure transparency across teams and the broader organization. They offer structured ways of running sprints, documenting decisions, and providing visibility on what’s being worked on. However, the real value of these tools tends to accumulate at the organizational level—not at the individual contributor level.

For the engineers writing code, designers crafting experiences in Figma, and product managers shaping features, project management is often just another layer of busy work. Every moment spent creating or updating tickets, assigning tasks, or meticulously documenting decisions takes time away from their core, productive work.

Even if a tool is elegant and easy to use, the friction remains: it’s still a distraction from what people are truly hired to do.

Input – the biggest problem

The heart of the issue is fundamentally about inputting information. The 'busy work' of updating project management tools occurs most frequently following meetings. After discussions, decisions, and compromises, ideally, all this new information should seamlessly appear in the team's project management system. Yet, in reality, this rarely happens because documenting these outcomes is tedious.

At Superthread, we've shifted our focus toward solving this input problem head-on.

Zero overhead project management

Our new direction is simple yet powerful. We're integrating advanced transcription capabilities directly into our macOS desktop app. When you have meetings—whether in-person or virtual—you simply turn on transcription. Our app transcribes the conversation in real time without storing any audio, ensuring complete privacy and control.

Once your conversation ends, Superthread automatically:

• Reviews the transcript and your meeting notes.

• Searches your entire workspace to identify related existing tasks, projects, or documentation.

• Suggests updates to tasks or the creation of new tasks if necessary, complete with recommended titles, descriptions, and assignees.

• Highlights decisions made during the meeting, drafting comments and status updates for relevant tasks to keep everyone informed effortlessly.

Instead of manually sifting through project boards, writing tickets, and assigning them, you simply review and approve the suggestions. Superthread handles the tedious busy work, freeing you to immediately return to coding, designing, or planning.

The future of project management is invisible

We're convinced the future of project management involves even less direct interaction. Eventually, input might be as simple as speaking or dictating instructions, with the tool intelligently managing tasks, updates, and documentation behind the scenes.

The goal is clear: Project management should enhance productivity without adding overhead. It should quietly enable teams and organizations without forcing individuals into repetitive, distracting chores.

At Superthread, this vision guides our next steps. We're committed to creating a tool that works for you, in the background, so you can stay focused on your real work. The best project management tool, we're certain, will ultimately be the one you barely notice at all.

Input: CEOs, team leads, and individual contributors often find it cumbersome to input information into project management tools. This reluctance stems from various factors, including the clunky and slow nature of current tools.

Output: Extracting useful information from project management tools proves to be a daunting task. Different stakeholders, such as C-level executives, team leads, and individual contributors, require distinct data at varying levels of detail. Unfortunately, current tools struggle to accommodate these diverse needs effectively.

Search: Although project management tools offer search functionality, they encounter significant difficulty in providing relevant result sets, especially as workspaces become inundated with content over time.

At Superthread, we're currently honing in on these challenges. We firmly believe that by combining simple software craftsmanship & quality with AI, we can elevate the experience for everyone involved and pave the way for numerous successful projects.

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.

To address this problem, I had to undertake a significant effort to optimize the database performance.

After improving the performance, I moved on to start a game engine company. There, I developed a browser-based game engine bundled with a backend for managing players and community assets. It quickly became apparent that SQL wasn't suitable for handling high-intensity games. After some research, I discovered Cassandra DB, which was one of the first open-source NoSQL databases.

Programming for NoSQL was different from SQL. No joins were possible, so you had to prepare and store the data in a single document, enabling lightning-fast lookups. It required an initial investment of effort, but it proved effective.

Since then, I've exclusively worked with NoSQL databases. The most significant project I used it on was a game with 50 million downloads and over 10,000 concurrent users at its peak, and the database never experienced issues.

At Superthread, a Project Management Software with tasks and documents, we made the deliberate choice to build a fully NoSQL microservice architecture from the outset. Although it took a bit longer to set up, it resulted in a highly scalable system. This means that whether you have 10 or 10 million records, the system's speed remains consistent.

You can also watch a video version of this article:

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.

When I started building the Superthread prototype, I decided to build the backend in Go (golang) even though I had never programmed in Go before.

The reason: I met some folk doing some low latency stuff who were passionate about Go and who persuaded me to try it.

To learn and code faster, I decided to write 100% unit and integration tests. This worked well because it allowed me to speculate without worrying that the other parts of the system would break. The plan worked and we continue with Go to this day.

On the front end side, I chose VueJS. Having done react previously, I realised that I preferred to work with Vue and especially I preferred VueX to Redux. In summary, I felt that Evan You’s approach was more reasonable.

On the database side, I decided to go with Redis because I used it previously as a primary DB on a huge system where it performed well. However, this approach was not scalable because it relied on developers adding records to sorted sets manually. We then tried a commercial version of Redis which had the required indexing functionality but it turned out to be flakey. We then decided to switch to DynamoDB (with streams) as part of our move from GC to AWS. This is supported by SQS and SNS.

When it comes to orchestration, we went from Kubernetes to ECS mainly because the leads decided to move to AWS. I used to be all in on k8s but now I am pretty agnostic.

As we stand we are pretty happy with our stack.

Since this is a pretty high-level overview, I go into a bit more depth in my latest YouTube video and at some point we will go deeper since we are doing a lot of stuff with AI and and testing frameworks.

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.

Comprehensive Demo and Feature Analysis of Superthread’s editor specifically crafted for our project management software.

See the innovative capabilities of our cutting-edge project management software editor in our latest demo. This in-depth showcase highlights the robust features and significant advancements we've achieved in our editor.

For a detailed look, here is our previous post featuring a detailed comparison table. It carefully contrasts the initial features and bugs with our current, enhanced version.

Key Features of Our Project Management Software editor which are demoed in the video:

• Internal Links: Streamline your workflow with efficient internal linking.

• Inline Comments: Enhance collaboration with seamless inline commenting.

• Mentions: Boost team communication with easy-to-use mention functionality.

• Images: Integrate visuals effortlessly with our image-handling capability.

• Tables: Organize data neatly with our versatile table feature.

• AI Extension: Empower your project management with our innovative AI extension.

• Bubble Menu: Experience intuitive navigation with our user-friendly bubble menu.

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.

Superthread is a lightening fast & beautifully crafted project management software with integrated tasks & docs.

Since text input is a crucial part of the system, we wanted to build the best text editing experience in the world.

We use text in Cards, Pages, Comments, Sub-comments as well as inline comments.

This table shows how we approached the problem.

We compared features and bugs with our original quill implementation, Lexical playground which is Meta’s open source offering & TiptTap playground.

The last two columns show our initial effort inside of “TipTap ST Implementation“ and where we are now (January 2024).

As you can see the stuff we are missing are mainly embeds which we expect to add shortly.

At the bottom of this page I have included the list of extensions which we custom built or extended.

You can try the editor by signing up on www.superthread.com

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.

With the rollout of Chat GPT 3.5 and its successor, version 4, artificial intelligence has surged in popularity. Once the domain of a select few enthusiasts, today the entire development community eagerly embraces its potential.

Yet, ChatGPT no longer stands alone. First came Bard, then Meta introduced LLama, followed by Anthropic's Claude, and now Gemeni, Deep Mind’s latest model.

The interesting thing about Gemeni, is that it is only marginally better than Open AI’s model. It is too early to say what this means but it could well mean that we have reached saturation point when it comes to the capabilities.

Regardless, it's reasonably certain that a plethora of Language Model (LLM) options awaits in the future, with affordability likely on the rise. In my view, unless we see the advent of Artificial General Intelligence (AGI), improvements are likely to be marginal, signaling a slowdown in LLM innovation.

This leads to the deduction that the next wave of AI innovation is within applications. In the past, molding and integrating a model into software took six months of training; now, a similar process only demands half an hour.

Given this, existing software services with data, users, and established processes are poised to gain the most from AI integration.

In our case, every aspect of our software seems primed for enhancement through AI—this is the journey we have embarked on.

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.

At Superthread, our mission is is to Solve Project Management with AI.

Presently, we've crafted a Task Tracker with integrated docs which is simple, swift, beautiful; a cut above the rest. Yet, substantial challenges persist, particularly in the areas of data input and extraction.

And so, our expedition into the realm of AI commenced. Initially we have done some sprinkling, a process where we've infused AI seamlessly into Superthread, yielding three features.

Enter the Text Assistant:

Embedded within Superthread's various corners like Tasks, Documents, and Comments is a text editor. We've introduced an assistant that empowers you to highlight text, triggering transformations. Currently it can do Simplifying, Summarising, altering Tone, and Translating, it proves invaluable for crafting specifications or detailing issues and bugs.

The Tag Suggestor :

With Superthread, when a card is created, it goes through our trained AI model which suggests a tag. At present, it's adept at distinguishing between features and bugs, with aspirations to broaden its scope to consider existing space tags for even more precise suggestions.

Duplication Suggestor:

In the chaotic landscape of project management, duplicate cards multiply, cluttering the workspace and sowing confusion. Our system steps in, detecting potential duplicates. Harnessing MiniLM, now residing on SageMaker, we've laid the groundwork for easy migration to future models like E5. We could also leverage OpenAI's capabilities for this task.

Yet, the transition between models comes with its nuances, requiring a comprehensive database scan and a revisit to the embedder for each item.

In Conclusion:

Our initial sprinkle of AI has proven its worth, which means that the users are finding it useful. But this is merely the surface; deeper innovations is coming. Stay tuned, for the journey has just begun.

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.

In '90, when I watched 2001: A Space Odyssey, I was floored. Mind-blowing! The aesthetics, the direction, super impressive, but above all, the concepts were mind-boggling.

The Intel 486 had just dropped, and its power was unreal. It felt like magic, a realm where anything, even HAL 9000, was feasible.

Naively, I thought, wouldn’t it be amazing if I could build something akin to HAL. University tossed me into an AI class by chance where I met exceptional peers and eccentric, intellectual mentors.

The project: craft a chat bot. My buddy's crew clinched first, mine second. They entered the Mega Lab for Tomorrow's World experiment. Their project came second in the country, excelling in dissecting Martin Scorsese's films.

My AI professor tapped me for his startup; where I stayed for more than a year. Life took its turn, but in my tech journey, I, like many nerds, took stabs at crafting a Turing-test-passing AI.

Fast forward, I built a game engine, launched a game engine startup which become a gaming company.

After exiting the gaming company I founded Superthread—an integrated Task Tracker with Docs where we aim to Solve Project Management using AI.

Superthread is an all-in-one project management and wiki app for small teams. It has projects, tasks, and docs integrated in one unified tool. Designed for cross-functional companies where engineers, product, design, marketing, and operations can work together.