Developer Stories

From Employee #1 to Product Leader: Peter's Journey at Lorikeet

Peter Nguyen shares his incredible journey from Lorikeet's first employee to product leader, navigating the dynamic world of AI-native startups and the evolving role of engineers.
March 23, 2026
If you work with incredibly smart people, then it's a recipe for success. You should always index on people, then on wildly ambitious ideas.

From Employee #1 to Product Leader: Peter's Journey at Lorikeet

Two and a half years ago, we interviewed Peter Nguyen just as he was joining Lorikeet as their first employee. Back then, the company was pre-product, the founding team numbered fewer than ten people, and the future was uncertain. Today, Lorikeet has grown to over 60 employees across the world and has automated over 3 million customer support tickets.

We sat down with Peter again to understand what that journey has really been like – from joining a startup before there was even a product, to transitioning from engineering to product management, and what it all reveals about building a career in AI-native startups.

This interview follows on from our earlier conversation with Peter and our interview with Lorikeet founder Steve Hind.

Tell us about Lorikeet and your journey since joining in 2023.

Lorikeet is an AI-enabled customer support platform that operates across all channels – whether it's email, chat or voice – automating customer support enquiries. Our mission is to be like a one-place concierge that a customer can contact through any mode of their choosing, and we can respond to and help customers out in any format they wish.We do not believe in solely using AI to “deflect” customers, but truly understanding and helping them solve complex and pressing issues.

We started in 2023 with a team at pre-seed stage of under 10, and most recently we've grown to about a team of over 60 people across the US, London and Sydney.

What was it like when you first joined?

When I first joined, we were still pre-product. The founders weren't sure what we were wanting to build exactly, but we had design partners who were willing to build with us.

Steve's background is from operations, and one of the pain points he'd seen was a lot of non-automated work – manual grind.  Back in 2023 when we started, we had GPT 3.5 and the API had just been released. People were just starting to think about what sort of applications we could build with this.

Back then everyone was talking about co-pilot solutions – how can we use AI to help people? But we thought one step further: how do we get AI to just do the automation end to end, so people can take a greater bird's eye view and guide the AI instead?

How quickly did you go from idea to product?

The week I started, we decided to build V0.1 of AI ticket automation. We were ingesting Zendesk tickets, coming up with Python scripts, passing it through an early email pipeline. We'd do side-by-side comparisons – could we answer a ticket better than a human could? It was very rudimentary.

Within about six months, we built an application where people could build their own workflows and connect to ticketing systems for the first time. We really kicked off in January 2024. The first three months were a lot of product discovery with Eucalyptus, our main pilot partner.

Now we've grown to many more customers. We hit 3 million automated support tickets at the end of last year.

Where is the company now in terms of its journey?

I still think it's early days. Most companies haven't even looked at automating their customer support process yet. And when they do, it's still very much "how can I do what I do now, but just replace it with an AI back end?"

The more interesting question is how this evolves into the future with new forms of support. For example, most support right now is reactive – people are just trying to keep on top of their incoming inbox. But when AI makes support effectively infinite, you can start proactively reaching out to your customers, instead of waiting for them to contact you when they have a problem. You don't have to worry about taking your inbox down to zero. You can actually help people and meet them where they're at.

So the current paradigm is still "let's automate and streamline." But there's going to be a completely new paradigm that opens up.

Are you trying to satisfy the old paradigm first, or tackle both at the same time?

We're trying to tackle both. On one hand, we have to meet customers where they're at. But we also have to be thinking about the future.

One of the big initiatives we were working on last year was voice, which is a completely new product. Until now, most of the world's voice bots have been not very useful, relying on pre-planned decision tree logic, forcing customers to speak in rigid statement. Now with AI, you can speak conversationally, reacting to the dynamic nature of speech. . It really kind of challenges how people receive support.

Before, companies might limit how customers could interact with them purely because they might not have the resources to open up a call centre operation or live chat operation. So maybe they'd start with email because it's more manageable. Now support is  almost infinite and instant. We see support shifting to more instant modes such as chat and voice.

How has your role evolved since joining?

I joined as a software engineer. If you want to start off on an early team, you want to be very well-rounded. It's good to have technical depth, but what early stage companies are looking for are product engineers – engineers who can talk to customers, who can find out what to build. Not simply be told what to build.

This ties in with how the profession is heading with AI as well. Now that code generation is infinite, the value you can bring is trying to find the problems worth solving, not just solving problems.

I spent about a year and a half wearing an engineering hat, but during that time I was talking to customers and doing product discovery work. Then I switched to product management middle of last year - since I was wearing a lot of hats as an engineer, the transition has not been too different!

Now that teams are no longer bottlenecked by engineering, having good product sensibility and high quality taste is becoming more important, and that is becoming everyone’s responsibility, not traditionally just PM or Design. In my focus at Lorikeet, taste is having sense for good conversation quality – how you can talk to someone, whether you express it in the right way, do you understand a customer’s past conversations? Then I switched to voice primarily for the last six months, focusing on quality of voice and interaction – was the latency fast enough to mimic real human interaction?

You mentioned "taste" – what does that mean exactly?

Product sensibility – knowing what is high quality and what is low quality. Is the product we're putting out into the world good quality?

In the world of evaluations, you can set up scorers. Within certain parameters, you ask: was the response empathetic to the customer? Did it draw upon a customer’s past interactions with the company? You can grade it, and then extrapolate that at scale to see how AI performs.

As a product manager, your job is to define those metrics – what counts as good taste – and then evaluate what the engineers have built against that. In practice, you also have to balance that with roadmap prioritisation and project management, but defining what good looks like is the core of the role.

What have you learnt by working at Lorikeet?

Wearing many hats and having agency. In this new paradigm, there's nothing stopping you from just shipping stuff without having to ask for permission. We'll often ship a prototype and then talk about it. 

There's not too much permission asking. It's just: let's validate it, let's ship it, let's see what happens, we'll react to it and keep iterating. That changes how you work – you're responsible for outcomes, not just tasks.

What's been the best part of the journey?

Being able to work on experimental parts, working with some of the most talented engineering and design talent. Talking to customers is definitely the highlight. The fact that you can create something, put it out there in the world and see how people react to it is richly rewarding.

Getting to see the team grow in size and scale, and the company having a greater impact over time. In the first year, we would do so much for even the smallest customers. These efforts compound, so when we scale up and start working with more enterprise customers, we've already had those lessons about what makes a good support interaction.

And the hardest part?

It's a double-edged sword. Being part of the AI space means we're at the frontier of technology. Inevitably, sometimes our experiments do really well and we can automate a lot of things. But sometimes they don't do what you want them to do. There's no guarantee.

The other thing is it's really exciting to keep on top of developments in the AI space. We talked earlier about Claude Code and the new Opus model – it's completely changed how people think about the industry. We're in this uncomfortable phase where we have to disrupt ourselves constantly and find new ways of working.

Because you're in such a highly competitive space, you naturally assume all your competitors are doing the same. You have to be the one to disrupt yourself first.

Do engineers at other companies face the same pressure, even if they're not in AI?

They will have the pressure whether they want to realise it or not. You need to be aware of what's out there on the horizon because things are definitely changing. Over the last month, if people have been keeping abreast of the news, it's undeniable that the profession will not be going back to the old way of doing things.

What specific changes are you referring to?

The new rise in coding agents. Obviously coding agents have been around, but the new capabilities offer so much velocity. Things you didn't think were possible are now possible. You see many back-end engineers shipping front-end code. PMs are shipping code, designers validating prototypes much earlier, engineers writing product specs. Everyone's doing a little bit of everything.

Also code is only one part of the picture -  it has also accelerated all internal functions from marketing, sales, operations and product. These generalist agents have allowed us to aggregate context across previously siloed and disparate sources, from slack, meeting recordings, source code and analytics. 

It means that implementation is limitless now, and right now we're bottlenecked on good ideas. It means we can iterate faster, bring things to market faster and validate them.

What should people do if they need to get up to speed?

Just start building. No matter what sort of technical or non-technical background you come from, you just need to immerse yourself in tools. Right now we have the capability of easily 5x-ing our output. This is just untapped potential.

What tools are you using?

Primarily Claude Code via the CLI as the command center, connected to Slack, Cursor, Notion and internal MCPs. This year I'm trying to ship one feature a week on top of all my PM stuff. It's my personal goal.

I think it's useful to stay on top of all developments. But it's not just feature work – you can use it to synthesise feedback. You can get AI to join all of your discovery calls, spit out a transcript, and summarise every week. You can just ask it: what are my priorities for the week?

As a PM, you're still shipping code?

Yeah. When you see a bug, you're just like, "I can fix that. Let's unblock people."

In traditional backlog management, you prioritise things and typically the low priority stuff never gets shipped. But often they are quality of life improvements. Now there's almost no friction to shipping all that. You can grab a whole bunch of low priority tickets and just ship them asynchronously while doing your day job.It takes no more mental bandwidth. A dev can spin up multiple parallel instances, get it working, then come back to it later. It'll get you 90% of the way there.

What has been the most rewarding thing recently?

Getting to work on voice, which is the cutting-edge new product Lorikeet has made.

What advice would you have for developers looking for similar opportunities?

Before we were bottlenecked on capabilities or technical ability. But now we're actually bottlenecked on agency. You don't have to have all the specific knowledge of that one domain – you just have to be determined to ask the right questions to get you there.

So the differentiator now is: how motivated are you? How much agency do you have to ship something? From having an idea to implementing it, how quickly can you close that loop?

This is where the future's headed, but also what small-scale startups are looking for. They're looking for people who can ship and think product at the same time. If you want to work at a small-scale startup, think of yourself as a product engineer. You want to be able to talk to customers and ideate.That being said, there is still high value in learning engineering fundamentals.

How did you decide Lorikeet was the right opportunity for you?

The talent density – the calibre of the people you work with. If you work with incredibly smart people, then it's a recipe for success. It doesn't matter what the idea is. You should always index on people, then on wildly ambitious ideas that are worth fighting for.

What else should people look for when joining a startup?

For small-scale startups, the ability to own and wear different hats. Ownership. The ability to go beyond what your traditional role at a bigger corporate would be.

How has joining Lorikeet impacted your trajectory as a tech professional?

In previous places, you're hired to be a software engineer and you’d be allocated a certain number of tickets for every two week sprint. We spent so much time estimating how long things would take, planning every ticket and over-coordinating.. Whereas now you're more responsible for outcomes. It's not about implementing features – it's about: you have a great idea, you implemented it, did it achieve the result you wanted to achieve?

I look at being a tech professional as outcomes-based. To be honest, now anyone can do anything - we are simply builders. Having a title doesn't mean you only do that thing. Maybe we're a special case in that we're small to medium scale enough where we can still be very amorphous about roles and responsibilities. But you shouldn't limit yourself to what you've always done.


What This Means For You

For Developers: Peter's journey shows what's possible when you join the right team at the right time. If you're looking for rapid career growth, exposure to cutting-edge AI technology, and the opportunity to wear multiple hats, early-stage startups like Lorikeet offer something traditional roles simply can't match.

Looking for your next opportunity? Create a profile on SkillsRobin and get connected to startup founders building the next generation of AI companies. Or browse off-market startup jobs that aren't advertised anywhere else.

For Founders: Finding someone like Peter – a product engineer who can talk to customers, ship code, and grow into leadership – is exactly what makes the difference between a startup that scales and one that stalls. The best talent isn't on job boards; they're in networks like SkillsRobin.

Ready to hire? Browse pre-vetted developers or post your role to get connected with technical talent who understand the startup journey.

Want to read more developer stories? Check out our interview with Jack, technical co-founder of Kumo Study. Or read about how Steve built Lorikeet from the ground up.

Discover opportunities on SkillsRobin

🌱  Hiring?

Get in touch with pre-vetted software engineers and UX designers based in Australia.

 🪴 Looking for a job or side hustle?

Create a profile on SkillsRobin and get invitations to connect from startup founders and hiring managers