Traditional product teams (PM โ Designer โ Engineer) pay five hidden taxes on their velocity.
AI is giving us the opportunity to eliminate these taxes.
Allowing teams to ship absurdly fast.
The root of the problem is boundaries between roles.
Every time work crosses a boundary, you pay a tax.
These are the taxes.
1. Handoffs โ time spent transferring context to the next role.
2. Queues โ time spent sitting idle waiting for the next role to free up.
3. Back-and-forth โ time spent stalled on unforeseen clarifications.
4. Idle capacity โ time spent underutilized because the workflow is bottlenecked on another role.
5. Split context โ decisions made without seeing the full picture.
So how do you eliminate these taxes?
Enter the product engineer.
Collapse product, design, and engineering into a single role.
AI has shrunk the skill gap enough that an engineer can design, and a designer can write code.
One person figures out what users need, designs the solution, and builds it.
The boundaries disappear.
No handoffs.
No queues.
No split context.
You just ship.
And this isn't just theory for early-stage startups.
High-velocity product teams are already structured this way.
Companies like PostHog and Linear are leaning into the Product Engineer role.
We use this model at Lira, and it has been a game-changer.
Beyond the shipping speed, it's just plain fun.
When you know how your work impacts real customers, the software you write means more.
What other companies are you seeing move towards a Product Engineer model?
AI made you 10x faster at writing software.
But it takes more than an AI agent to move the business 10x faster.
It takes changing how you work.
So what do you do with this new speed?
The key is that AI doesnโt just let you code faster.
It lets you learn faster.
Design โ Build โ Ship โ Measure.
That product development loop used to take weeks.
Now you can run it in one.
But only if you rebuild your workflows around it.
This is what allows you to go from shipping 10x code.
To shipping 10x validated solutions that customers pay for.
For us that means a weekly sprint.
Mon โ talk to users and dig into the weekend's data.
Tues โ start with the most important thing to build.
Wed & Thurs โ keep building, working down the priority list.
Fri โ ship it and let strangers use it over the weekend.
Monday morning the answers are waiting.
We run this process 50 times a year.
50 chances to learn what people want.
And that's the real gain. Not the code you write, the learnings you get.
That's the difference between shipping 10x more code and shipping 10x more solutions customers pay for.
Day 30/30 โ We launched ๐
30 days ago, I started a challenge to share the journey of building something from scratch. One day at a time.
Today, itโs live.
Our AI Communications Coach is out in the world.
The last month has been equal parts fun, messy, and exhausting.
What Iโve taken away:
๐ต Showing up daily builds momentum
๐ต Early feedback > perfection
๐ต Consistency turns ideas into progress
Thanks to everyone who followed along, shared feedback, or just encouraged me to keep posting. You made this way more meaningful.
Now that the 30 days are up, Iโm not stopping. I'm just shifting from building in public to growing in public.
Day 29/30 โย One day left.
The real win wasn't the follower count or engagement stats. It was showing up daily even when progress felt slow.
Shipping features that weren't perfect. Sharing updates publicly when I wanted to hide.
This 30-day constraint forced a habit I needed. Transparency over perfection.
See you for day 30.
Day 28/30
Wrapped another late night session.
โ Payments flow live
โ File uploads working
โ URL integration ready
The product is finally feeling real.
9 user interviews lined up this week. FB ads go live Tuesday.
Two days left in this challenge. And three days until launch.
The exhaustion is real, but so is the momentum.
Day 27/30
Friday night and I'm still coding.
We're launching next week. And there's still so much to build.
But honestly, I'm exactly where I want to be.
Who else chose code over going out tonight?
Day 25/30
10 years of coding, 2 years with AI.
Here's what I've learned.
โ DO:
- Understand AI code before committing
- Use it as a learning tool
- Leverage autocomplete & boilerplate generation
โ DON'T:
- Blindly trust generated code
- Give AI large, vague tasks
- Delegate your understanding to AI
AI is a force multiplier, not a replacement for thinking.
Day 22/30 - Dogfooding my own product.
In the past, I've stumbled through conversations with angel investors.
As the CTO, I talk about my business like I'm reading tech specs.
So I used Lira to help me practice.
It took my 5 reps to feel confident and fluent.
๐ก Attempt 1: "Intermediate" - way too in the weeds
๐ข Attempt 3: "Advanced" - better, but still missing something
๐ Attempt 5: "Elite" - finally found my voice
Practice helps. I really hope this can help other technical founders too.