Antony Ede is a Partner at New+Improved, leading product and technical development across all ventures before a founding CPO is hired. Ant began his career in data science and machine learning in New Zealand and London, and has since spent over a decade building and operating pre-seed and seed-stage companies. Along the way, Ant has co-founded several startups, so he has extensive first-hand experience on what it takes to build a successful product that scales globally. Ant has impressive, spicy views on moats and what PFM actually means for startups. Enjoy getting to know Ant!
1. Let’s start honestly. What is your biggest product-building mistake?
The biggest mistake is the most obvious one, but also the easiest one to make: building something that nobody really wants. There’s that YC line, “make something people want”. It sounds so simple that you can almost stop hearing it. But the hard bit is that founders are usually smart enough to build interesting things, and interesting things can feel like progress.
I’ve been guilty of starting with something I wanted to see in the world, then working backwards to find a market for it. That is dangerous, because for the first few months, it feels exciting. You are learning, building, making something clever, and convincing yourself the market will catch up. Then a year later, if the pain is not real, it is suddenly not fun at all.
The lesson for me is that product market fit (PMF) starts with the problem, not the solution. You can always improve a solution, but it’s very hard to come back later and choose a different problem. At the end of the day, if the problem isn’t painful enough for the customer, you’re never going to get to PMF.
So the discipline now is to find the painful, specific, budget-connected problem first. If the pain is juicy enough, you can take several swings at solving it. If the pain is weak, you are mostly wasting your time on something that won’t reach breakout velocity.
2. What gets you out of bed in the morning?
I like building things that have real impact on the world, even if it is in a very practical, unglamorous way. I am not especially motivated by abstract startup theatre. I like the bit where you find a hard, messy problem, understand it properly, and turn that into something useful that people actually use. There is something satisfying about leaving things better than you found them, whether that is a product, a company, a team, or a category.
The other part is that I genuinely enjoy solving interesting problems with good people. Startups are pretty unforgiving. Most of the time you are wrong and you have to keep updating your beliefs. But when you get a team moving quickly, talking to customers, shipping product, learning, and correcting course, it is an incredibly fun way to spend your time. You can see an idea go from a conversation to a prototype to something in a customer’s hands to a company with its own momentum.
3. In a few sentences of your own, what is your role at New+Improved?
My role is to understand what users really want and translate that into a product that actually works.
That starts in customer conversations, where we are trying to work out the real pain underneath what people are saying. Then it moves through proposition, prototype, product shape, build decisions, and eventually into something customers can use. I work very closely with Ashish, our lead developer, who has been the person making so much of this real across Tracksuit, Ideally, Drumbeat and the other products we have built. We can dream things up, but Ashish is the one who can turn them around at absurd speed.
In the early stages of a venture, I focus on finding the initial spark of PMF and iterating on it quickly. As founding product team members join, I work alongside them to strengthen the product and deepen our understanding of the user problem and complete solution.
4. How is AI changing how quickly you can validate and launch new startups?
AI has changed the speed of company creation dramatically, and I think we are only just starting to understand the implications.
The release of Opus 4.5 in November 2025 felt like one of those moments we will look back on as genuinely pivotal. I do not say that lightly. It felt like a step change in how much of the product building process could be accelerated, especially in the messy early phase where speed of learning matters more than elegance.
The biggest shift is not just faster code generation. It’s that the loop between hypothesis, prototype, customer feedback, and iteration has compressed. What used to take weeks to get in front of a customer can now be built in minutes, allowing teams to learn and iterate significantly faster. And in the 0-1 stage, learning speed is everything. Early products are mostly guesses. Some of those guesses are right, some are wrong, and some are half right. AI lets you push more guesses through the system and find out sooner.
But the trap is that AI can also make it easier to build the wrong thing. Technical feasibility is less of a constraint than it used to be, which means commercial and product judgment matters even more. The hardest question is what you should build?
5. How does AI change what counts as a moat in early-stage companies?
I am pretty sceptical of moats in general and especially at the pre-seed stage. The first job is not to defend the castle. The first job is to build a castle worth defending.
Moats can become a distraction from the real work of building the company. At pre-Series A stage, where I spend most of my time, you often don’t know exactly who the customer is, what the sharpest use case is, how the product should work, what people will pay, or whether customers will use it repeatedly. So talking too confidently about a moat is mostly theatre.
One of my favourite Paul Graham quotes is“Startups die by suicide, not murder”. I think this captures the obsession with external vs internal issues perfectly.
6. What are the key aspects to consider for distribution in the earliest stages, before a startup has had a chance to prove PMF?
Pre-PMF, sales and distribution are primarily a research function. You are not yet building a scalable go-to-market machine because you don’t know enough. Instead, you are trying to understand who feels the pain most acutely, how they describe it, how they currently solve it, where it sits in their budget, who is involved in the buying decision, and, most importantly, what they will actually pay. People can tell you an idea is great all day long, but if it doesn’t cost them anything (in dollars, reputation, time, etc.), that feedback is useless.
Real customers paying for the product is the only true signal of how real the pain is.
One of the biggest mistakes we have made in ventures is trying to scale distribution before PMF has been achieved. It is tempting, as once you have some early sales or a good looking proposition, the instinct is to add salespeople, build the funnel, turn up demand generation, and make the machine bigger. That’s a mistake in my experience. It has to be a sequential process.
First, get PMF: prove that a specific customer has a specific pain, will pay for a specific solution, and will use it repeatedly because it creates real value. Then get go-to-market fit: work out the repeatable way to reach and convert those customers. Only then should you scale, and fast.
7. Where do startups go wrong when trying to find PMF?
Thinking you can increase PMF by improving the solution, when the real issue is that there is not enough pain in the problem.
If customers are not pulling hard enough, you assume the onboarding needs to be better, the positioning needs to be clearer, or you just need that one more feature that’s almost done. The reality is that a customer will use a product with strong PMF even when the onboarding sucks, it breaks and it’s expensive. Counterintuitively, leaving some of these things in a substandard state can be healthy friction and a great way to test whether the user is really motivated to use the product.
Another mistake is treating PMF as binary. It’s often framed as something you either have or don’t, but it’s a spectrum. You can have weak PMF, where some customers buy but the product still needs heavy pushing. Emerging PMF, where usage and value start to repeat, but demand is still inconsistent. Strong PMF, where the market begins to pull the company forward. As a product person, you don’t “achieve” PMF, you continuously work to strengthen it.
The goal is to get to a point where customers are falling over themselves to get the product. They are recommending it to anyone they can. They are expanding their usage without needing to be begged. They are asking what else you can solve for them. Sometimes they are even asking to join the company, because they can see the opportunity so clearly. That is the kind of energy you are looking for. PMF is not a badge you award yourself after a few promising sales. It is a level of market pull you keep trying to make stronger.
8. What are the clearest patterns you see across all the successful startups you have founded and worked with?
It comes down to two things: strong PMF and a strong founding team. Those two are simple in theory, but at the same time, most complex in practice.
If the market does not really want the thing, the team ends up pushing the company uphill forever. If the founding team isn’t strong enough, even a good opportunity can be missed because the company can’t capitalise on it.
As mentioned, strong PMF is the combination of strong user pain and rapid product velocity. The founding team is the other half of it. In the early stages, the company is still incredibly malleable, so the strengths of the founders matter enormously. You need people who can sit close to the customer, make good decisions with incomplete information, move quickly without creating chaos, prioritise constantly and keep going when the first version of the plan turns out to be wrong.
9. What makes a successful product hire in a 0-1 startup?
A successful product hire in a 0-1 startup is very different from a successful product hire in a later-stage company. In a pre-PMF company, you are iterating the entire company for dear life. The customer, problem, positioning, product, onboarding and sometimes even the category are all still moving.
So for a founding CPO or first product leader, I would look for someone who has lived in that ambiguity and thrived in it. They need to be close to customers, not operating through layers of abstraction. They need to be able to hear messy signals and turn them into a simple product direction. They need enough technical understanding to make good trade-offs, but they do not need to be the fanciest technologist in the room.
10. What are you intentionally working on right now as a leader?
The thing I am spending the most time thinking about right now is how AI changes the product development process itself. After the Opus 4.5 moment, the whole profession is up in the air and there are many people, including me, trying to figure out where the dust will settle.
What do engineers do when Claude is the best programmer on the team? It is not about typing every line of code but rather about problem decomposition, architecture, taste, review, safety, context, and most of all knowing what should not be built. The best engineers will not be replaced by AI, but the shape of their leverage is changing quickly. Adjacent roles like product managers and designers are changing in similar ways.
Ultimately, the technical barriers to building are falling away. If you can build anything, the question becomes: what should you build? That pushes us back to the fundamentals: customer pain, product judgement, taste, distribution, and the ability to learn quickly. I am trying to work out how we build teams, processes and habits that are native to that world, rather than taking the old product development model and sprinkling AI tools over the top.
11. What did you want to do when you were younger?
Ever since I was young, I was always pulling things apart to see how they worked. Over time, I got a bit better at putting them back together as well. I loved puzzles and problem-solving, and I was always drawn to things where there was a system underneath it that you had to understand before you could make it work properly.
Later, when I got into data science and then more into software development, I realised that writing software is basically an interesting puzzle and problem-solving job. You are trying to understand the shape of a problem, break it down, work out the constraints, and then build something that behaves the way it should.
Over time, though, I realised that great products alone do not solve problems at scale. You need great businesses wrapped around them. So my passion shifted from just building great products to building great companies, and solving the wider set of problems that involves.
12. What’s the best piece of advice you’ve ever received?
The advice I come back to most is to "enjoy the journey". Our brains are very good at tricking us into thinking life is all about the destination. Once I get the next thing, then I will be happy. Once the company raises, once the product launches, once we hit the revenue target, once there is a big exit, then I will relax and enjoy it. But of course, that is not really how it works. You get there, it feels good for five minutes, and then your brain quietly moves the goalposts.
This is especially relevant in startups. The startup world can make people quite unwell if they are only focused on the mythical end point. People kill themselves for the billion-dollar exit, but the exit is not where most of your life is spent. Your life is spent in the building process.
We hoped you enjoyed getting to know the incredible Ant more. Connect with Ant here!
