I debated whether to publish these raw thoughts. Then I decided I don’t have to be polished all the time. And I tried not to overthink it.

Let me know what you think about it. More constructive product management articles are coming over the next few weeks.

I’m conflicted between these two opposing approaches to posting content online:

1. You project success, show the good bits, make everything look very aspirational.

2. You are honest, show your meagre follower count, and recount all the things you’ve tried that failed to significantly increase your audience.

I don’t want to deceive people. I also don’t want to produce more “overnight success” content and pose as someone who has “made it” – whatever that means.

At the same time, everywhere I look, I see the “5 things that will solve all your problems” lists with millions of views, and the “here’s the formula for success” carousels.

On paper, I might seem successful, but often I don’t feel like it.

The definition of “success” I use here is “you are a business person who has figured out how to comfortably live off their skills.”

Of course, there is more to success than that. But I can still feel unimpressed with myself, even if I’m writing these lines from a cool Estonian bookshop-café, without being monitored by a manager.

Why is it so hard to be satisfied with what we’ve got?

It’s the constant comparison. You know that experiment where two monkeys were getting cucumbers for the same task they successfully completed, and they were perfectly content. Then the scientists started to give one of the monkeys sweet grapes, instead of the watery cucumber for the same task, and the cucumber-fed primate lashed out. It was perfectly satisfied with the cucumber until its counterpart got a more delicious treat.

In an episode of Lenny’s podcast, a billionaire said that there will always be another billionaire with a bigger super yacht, and that’s why so many of them are actually miserable. It sounds ridiculous, doesn’t it? I’d think that a billionaire’s biggest problem is making sure their money is invested into something safe, so they can just comfortably live off the interest. But it’s human nature (and monkeys’ too).

So, what can you do? What can I do to appreciate my situation?

Stop scrolling Instagram, LinkedIn, and just get back to work. Or go outside, nature is a surprisingly lovely antidote to all this nonsense.

Well, I did take a walk, and actually got some clarity. In the messiness of all the emotions I’ve had, I forgot to ask myself, “Why am I doing all of this: posting on LinkedIn, writing articles, or even creating courses for Little Parrot?” I want to help women benefit more from technology.

So, the question is then, “How can I do that better?” I think presenting an honest picture of what building a business is really like is more helpful, than sharing only the shiny façade.

I know that I rebel against the hype and guru positioning, and I don’t want to put more anxiety into the world. So, maybe it can help someone to know that I do doubt sometimes if we are going to achieve a bigger positive impact.

I’m curious, what do you enjoy reading more: people’s advice who have figured out how to live off their passion, or honest accounts of not succeeding?

Also, let me know if reading this article was valuable for you in any way where I worked through some stuff in real time. Or if you’d rather stick to articles on fully formed ideas and practical techniques.

Thanks for being here,

Kinga

But what’s the point of all this stuff?

When it comes to a new product, it might be easier and cheaper to build it, but the expensive part is still figuring out the right distribution channels. When I say “distribution”, I simply mean how our target audience finds what we’ve built.

Building a product is like 25% of the job. The other 75% looks a bit like this:

1. You need to make sure it solves a real problem for your target users to make it valuable.

2. You need a lot of people with that specific problem to find it. That’s distribution.

3. Your target audience needs to have time to try it, and find it useful enough to come back to it over and over. So, you also need to drive the behaviour change required for them to adopt the product.

4. And finally, the holy grail of a business: revenue. You need to make sure this product is so valuable that your users will happily pay for it.

For a B2C product, getting to the point where you have enough paying users to comfortably live off the income takes a lot of time and experimentation. Unless, of course, you’re a “tech bro” with a massive network of influential people ready to amplify your launch, meaning you don’t have to figure out scrappy ways to reach your audience.

We aren’t in that camp. With Little Parrot, we’ve validated that we’re building something that solves a real problem, but the bit we haven’t figured out yet is distribution. What are the channels that will bring in new users in a sustained way?

We intentionally avoided paid marketing so far. Instead of throwing money at the problem, which might not even yield results, we want to validate which organic channels actually work for us first, and that our messaging resonates.

Our experiments

We’ve been running a couple of experiments to identify where our target audience hangs out and where we should focus our energy.

Instagram

Instagram was one of the channels that we experimented with last year. We consistently posted carousels featuring product management cartoons. What we learned was that static images and carousels aren’t the best medium for reaching people who don’t follow you yet.

Our new hypothesis is that videos, specifically reels, is the way forward. So this is what we are testing next. We’ve already seen that reels get way more views from non-follower, than carousels.

I recently read that if you add music to a carousel, Instagram treats it similarly to a reel, giving it a much bigger reach than a completely silent post. Based on our experiments so far, this hasn’t been true for us. Two carousels we published this way still only reached people already following us.

I’ll report back when we have more definitive results.

LinkedIn

The other week, I was at an event where I chatted with one of the initiators of EU-INC, a grassroots campaign for a standard startup incorporation form in the EU that was recently presented to the European Commission. Their petition was signed and supported by almost every famous startup founder in Europe (from Stripe and Wise to Lovable and ElevenLabs). Naturally, I was curious: how did a 10-person team manage to rally such massive public support for a policy proposal? What was their main distribution channel?

The answer was LinkedIn. One side of me was glad to hear this, because we all have access to LinkedIn. It feels empowering to know we have agency. The other side of me was a bit annoyed. Posting on LinkedIn feels like a chore. I hate telling people, “Look at me, look what great things I’m making!”

Even though I try to reframe it and follow my rule of only posting stuff on LinkedIn that might be helpful for someone else – a thought-provoking concept, or a tool they could use – it’s still hard. I think the underlying issue is something that many women are taught from an early age: be small, be silent, don’t bother others with your opinion. It enrages me, but I still feel that subconscious reluctance to share and “bother” people on LinkedIn.

Writing articles is one thing. If you are not interested, then you won’t read it. But a LinkedIn post pops up on your feed without you opting in.

Well, actually, I’ve just realised you have opted in. You have connected with me or followed me, so you have to see what I’m up to. Hm, writing really does help with thinking. All those people who say “don’t outsource your thinking to AI” have a point.

All this to say: LinkedIn is an important distribution platform (unfortunately). For Little Parrot, it’s been the strongest acquisition channel so far.

Conferences

The problem with conferences is that your activity there doesn’t scale. At the same time, when starting to build your business, you need to do things that don’t scale. The founders of Airbnb famously went door to door in the early days to convince people to sign up to their platform. The idea is that once you have enough users, the referral flywheel starts moving.

Last year, we gave talks and workshops at five conferences. At the time, we had only one course on Little Parrot, and at some conferences the audience wasn’t the right target for us. But what we learned was that conferences are a great way to build awareness about your product.

Communities

Posting in different communities is tricky, because you don’t want to just “sell” your product. You want to offer value to the members. I suppose this is true for every channel, even if your product aims to help them, you need to give something extra upfront.

If you find the right community, it can be a great acquisition channel. The key is to be razor-sharp with your targeting.

For us, we’re building Little Parrot with women in mind who can’t code yet, they might be founders, freelancers, or employees at a company. What connects them is an interest in building digital products, whether as a core business, a tool to support their business (like a lead magnet), or to communicate ideas at work.

The other thread we’ve started to develop more courses around is using AI to save time. We aren’t really interested in the “10x product manager” narrative, we just want to enable people to do their work more quickly so they can spend time on activities they enjoy.

So, those are the communities we’re focusing on, trying to give them value alongside letting them know our AI and vibe coding courses exist.

Subscribe now

Accelerate learning, not delivery speed

The right metric isn’t lines of code produced (it never was), or number of new products shipped, but value created that translates to revenue.

Of course, value creation is a notoriously hard thing to measure. A good proxy metric is how much you learn along the way. This helps you figure out what works and what doesn’t. Because value creation is an iterative process, you need to reflect on the outcomes of your activities to improve and get closer to making a positive impact.

The current narrative tells us that because AI makes building digital products so cheap, we can just test everything live in production. But constantly changing the UI creates a heavy mental load for your users (I’m looking at you, Lovable!). Plus, if you create a mountain of output with AI but your token costs end up sky-high, you haven’t built a sustainable business. You probably should have run smaller, cheaper experiments first, rather than producing stuff that not enough people are willing to pay for.

At the end of the day, our goal shouldn’t be to use AI to speed up delivery just for the sake of more output. The real superpower of AI is its ability to accelerate our learning speed. Build less, learn faster, and focus on the part that is crucial: finding your people.

Thanks for being here,

Kinga

It’s the first digital product of my two-person company, productkind. Our mission is to close the gender gap in AI adoption.

We are in the middle of 2026, and this made me reflect.

2025 was the first full year of my micro-business era where I experimented with various activities. One of them was building a digital product, Little Parrot, that offers micro-courses to women to help them build digital products.

It didn’t start out that way.

First, we focused on product managers, because I saw a gap in courses that develop practical skills.

But I yearned to do something more mission driven. And since I now have the freedom to work on what I want, we pivoted to helping women build digital products with AI.

I know AI is currently a massive buzzword. However, if it’s used well, it truly can speed things up and empower people to build digital products even if they cannot code yet.

What Didn’t Work

1. Posting Comics on Instagram

We consistently posted three product-development-related comics and a carousel of my latest articles on Instagram each week for 19 weeks. We started from 0 followers and in January this year we had 33. We posted 76 posts and we’re following 15 accounts.

I don’t need to look at any industry benchmarks to know that is a tiny number.

Yes, we haven’t promoted this account much. No paid ads whatsoever and only some promotion on Reddit, but not in the channels that our real target audience frequents.

Many Reddit groups have very strict rules on self-promotion.

Our goal with the Instagram account was to share these articles on there as well, provide value through comics and articles, and ultimately guide users over to Little Parrot.

Instead, we learned that carousels don’t get pushed out to non-followers, so they’re actually a bad way to get discovered on Instagram.

2. Posting Comics on Substack Notes

To get more out of the comics we created, since they took quite significant time investment, I also posted them on Substack Notes.

There wasn’t much engagement.

Since then, I’ve read that images and videos are not shown to as many people on Notes as written content.

3. Freestyling My Work Days

I’m the kind of person who loves to organise things, especially digitally. Organising user interview findings or creating structure for a workshop is my happy place, especially if a cup of light-roasted Ethiopian coffee is involved. ☕️

At the same time, living within too much structure kills my creativity. I need space to thrive and being confined to a rigid work schedule suffocates me.

So when I went solo, I decided to take each day as it came. Whatever I felt like that day I’d work on. Quickly enough, this proved to be exhausting. Every day having to make a decision on what to do out of the unlimited options felt draining.

So this year, we’re trying something a bit more structured. We’re trialling planning ahead for a single week. It also helps that I’m no longer working alone, because we are two of us now, so I can share and discuss ideas. I’ll write about our findings of this new workflow in a future post.

What Worked

Okay, now let’s look at the activities that we consider a success.

1. Writing Articles on Substack

I convinced myself several times that it was a bad idea to start my newsletter.

“There are already too many people doing the same.”

“Who do you think you are?”

“You’re late, you should have started earlier.”

Do these thoughts sound familiar?

If they do, then I encourage you to tell those limiting thoughts to shut up and just do the thing you want to do.

Everyone has that project they think about putting out into the world, but then their limiting thoughts intervene. I have them even after starting this newsletter and getting encouraging feedback.

I got feedback that the articles have been helpful for people. My goal with writing was exactly that: to help people feel more confident in building digital products.

2. Collaborating with Lovable

I started using Lovable in January 2025. It allowed me to create products without having to code that felt very powerful. In the spring, they put out a call for Lovable Shipped, a six-week hackathon. That’s when I became a subscriber and started working with it every week.

This was the time I started building our microlearning platform, Little Parrot.

I ended up finishing at #40 in the competition. This placement hasn’t contributed to our business in any way, but the accountability the program provided helped me to make steady progress on this product for six consecutive weeks.

In the autumn, Lovable organised another competition, specifically for women. SheBuilds on Lovable was a 48-hour buildathon where I experimented with a new product.

It was intense, but the community felt different than in the Shipped competition. It didn’t feel like a competition at all, but rather like a support group.

Afterwards, I had a chat with , Lovable’s amazing community manager. She’s so passionate about encouraging women to build products to make their side-businesses come true or enhance their existing venture.

This competition inspired me to change the direction of Little Parrot, and to focus on women who can’t code yet.

3. Giving Talks and Running Workshops at Conferences

When I applied to several conferences at the beginning of the year, I didn’t have Little Parrot yet. I wasn’t building productkind with the mission we currently have to close the gender gap in AI adoption.

All I wanted to do was practise public speaking. I gave several talks inside various companies I worked at. But speaking at a conference is different. Up to that point, I had only spoken at one conference.

I got accepted to five conferences in 2025. I gave talks at two of them and ran workshops at three.

It turned out that connecting with your target audience at conferences is a good way to better understand their pain points and also to acquire new users.

But for this to work, you need to be crystal clear on who your target audience is. We went to two conferences where the main audience was backend developers. It was interesting, we learned things, but we had very low conversion rate on both our newsletter (this one) and our courses on Little Parrot.

Meanwhile, when I gave a talk at a product management conference, a significant number of people subscribed to this newsletter (thank you if you’re reading this!). I’ll share more in a future article about this experience and useful techniques you might want to adapt for your business.

4. Building a Digital Product with Lovable

I started building Little Parrot with Lovable. The “0 to 1” part felt really powerful: it was quick, there was something to test with potential users right away.

Then, as the product and its complexity grew, came the more frustrating bit. Lovable has improved a lot in this past year and they are constantly making the product better. But when I was integrating Stripe as the payment provider last summer, things got really frustrating.

I had to enlist the help of my software developer partner – who since joined my venture. Now, I know, not everyone has a software developer on speed-dial. That’s partially the reason we’re building approachable, practical courses on vibe coding (shameless plug: check out our courses on Little Parrot 😉).

Overall, I learned that there are several techniques that prevent you from getting stuck in a loop of fixing things that continuously break. We also built these learnings into our courses. Using a vibe coding tool to build your digital product speeds you up, so you can test its value quicker.

Onwards!

I plan to dive deeper into each of these areas and share the ins and outs of what were the techniques that worked for us.

If you’re brave, let me know in the comments what you’d like to know more about. If you prefer privacy, just reply to this email or message me directly.

Thanks for being here,

Kinga

It’s been a little while since you last heard from me, and I’ve been doing quite a bit of reflecting in the meantime. I’d like to share the exciting changes you can expect in this newsletter.

If you’re new here, welcome! Here are my most popular posts from 2025:

1. How to Share Bad News

2. How I Got Into Product Management – and You Can Too

3. The Dilemma of the MVP

Finding a New Impact

Throughout 2025, I experimented with different revenue streams. When I say “revenue streams,” I mean doing work that makes me fulfilled, has a positive social impact, and also (not insignificantly) pays the bills.

This turned out to be quite a challenging combination.

I left my full-time job at the end of 2024 to do something impactful. I’ve worked in tech for 11 years, the bulk of which was spent in product management.

I love product management. It’s such a complex and exciting amalgamation of diverse areas: business, technology, design, psychology. I hadn’t had enough of that.

But to be perfectly honest, I’d reached my limit with the corporate side of things.

I was tired of the corporate politics, the lack of real value, and building products that executives wanted, while the people actually using them had different ideas.

Call me idealistic, but I wanted to have a positive impact beyond increasing revenue for shareholders.

I knew I wanted to help girls and women, though it felt vague at first.

I started by completing an executive coaching program. I loved mentoring, so I thought getting more tools through this program might be the way forward.

Did I enjoy coaching people? Yes; the nice ones.

It’s weird to admit, but I didn’t want to coach people who I didn’t share the same values with.

And, one of my inkling thoughts was that I wanted freedom. I wanted to be able to do my work from anywhere. I’m writing these lines from the veranda of the Botanical Art Gallery in Singapore. It’s an inspiring place.

Discovering Vibe Coding

I also began exploring AI and vibe coding tools, which allow you to build software without having to know how to code. I started building products, even though I don’t know TypeScript. And it was a really empowering feeling. So I gave talks, and ran workshops about my learnings.

By the summer, I started building Little Parrot, a micro-learning app to teach product and tech skills, primarily for product managers. I knew that world and I saw that practical skill development was still either too expensive or too theoretical.

In the autumn, I got accepted to the first cohort of SheBuilds on Lovable, a 48-hour hackathon for women. There, I saw a sea of professional women from various industries, all with ideas they wanted to build.

But I also noticed something frustrating: most vibe coding content is currently made by tech bros, for tech bros, in a way that doesn’t speak to women.

Closing the Gender Gap in Generative AI

In this publication, I primarily focused on corporate product management but I also want to write more about building products as a solopreneur or a micro-business. That’s exactly what we are doing at productkind, a 2-person company, and we believe sharing our learnings can be helpful for others.

After countless conversations with people at conferences and my partner, we have also refocused our work on our micro-course platform, Little Parrot, from teaching product managers, to helping women who can’t code yet, build digital products and use AI for their own benefit.

Our goal for these two pillars (the newsletter and the digital product) is to support each other. So we’re also introducing a new logo to signal that all the pillars belong together. We want this space to be inviting for anyone with a desire to build.

To understand why we feel so strongly about shifting from helping product managers to women, we have to look at how we got to a tech industry where women are a minority.

The term “software engineer” was actually coined by a woman, Margaret Hamilton, in 1963.1 By 1984, the share of computer science degrees awarded to women in the US peaked at 37.1%. But then, the numbers began to drop.2

What happened?

In the 1980s, a new technology, personal computers were marketed almost exclusively to boys and men.3 This meant that men saw themselves in software-related fields, and also had early access to computers. While women didn’t.

Now, a new technology is here: generative AI and amazing tools built on it, like vibe coding.

Yet again, most vibe coding influencers are men, and a meagre 14% of Lovable’s users are women.4 And this worries me, because you can only benefit from AI by using it.

I heard from Advait Sarkar, an AI researcher at the University of Cambridge, that you cannot develop AI literacy with all the “AI cheat sheets.” But you need to continuously experiment with the tools, and everyone develops AI literacy in their own specific way.

That’s why we need more voices who encourage women to experiment with vibe coding and other AI tools, so they see themselves using them. And they are able to produce high-quality output that helps them in their work.

Our mission

Our mission is to close the gender gap in AI technology adoption.

Women and non-binary folks should benefit from this new technology equally as men.

If you identify as a man, you are, of course, very welcome to stay. I want to build a community where everyone feels they belong, provided we all agree on one non-negotiable rule: being kind to one another.

Nobody has ten years of experience in vibe coding yet. We are all starting from the same line. We are all experimenting to figure out how to make our lives easier and build sustainable businesses with the help of AI.

What’s Coming Next

I plan to share my discoveries in an honest, transparent way.

Not in a “become a 10x product manager” way, but by sharing what I tried, what I learned, and how you can adapt those techniques.

I’ll share about:

• My hesitation to monetise my work

• Learnings from building a digital product in 2025: what worked and what definitely didn’t

• How I doubled my subscriber number and why then stopped posting

• Techniques we used to acquire users for our digital product

• And many more practical learnings

If there’s anything specific you’d like me to write about, please do leave a comment or send me a message.

And if you know a friend who might find this helpful, I’d be so grateful if you’d share it with them.

Share

Thanks for being here,

Kinga

At the time, I was just considering starting this newsletter, but repeatedly convinced myself that no one wanted to hear from me. And anyway, there are far more interesting voices in product.

“I’m a product manager in the tech industry,” I said. ‘Product manager’ is often a title that folks outside the tech industry – and sometimes within it – have no clue about. Software developer, yes, they write code. Designer, of course, they design screens and experiences. But product manager? They surely must be managing something. It’s probably important, because they have ‘manager’ in their title.

I had a hard time explaining more, because I wasn’t working for a company anymore. I left my full-time job the year before. I was still experimenting. There wasn’t a clear-cut label I could apply to myself.

My identity was built around what I did. So, was I still a product manager, even though I wasn’t actively managing a product?

Subscribe now

The Identity Crisis: What Happens When the Label Disappears?

We have a tendency to define ourselves narrowly by roles or achievements. But these attachments make our identities fragile when circumstances change.

Dr. Maya Shankar, a cognitive scientist, really helped me to rethink how to build a more resilient identity that’s not rooted in my job title. In her podcast, A Slight Change of Plans, she said:

“Rather than attaching your identity to specific pursuits, like being a mum or a writer or a podcaster, it can be better to anchor your identity to the underlying features of those pursuits that really make you light up, that really make you tick. It’s like, can I anchor my value and my worth and my sense of self not to what I do, but why I do it? Because that is the part of us that nothing in the universe can touch. It’s well protected forever, and then it helps guide you in your next pursuit.”

The problem was that I defined myself by what I was doing, instead of why I was doing it. As Dr. Shankar says, when we define ourselves by our underlying why (values, motivation, purpose), rather than our what (job titles or roles), our identity becomes more resilient.

We can then use this as our North Star when we’re facing inflection points in our life. Change happens when the roles, labels, or life structures we’ve tied our sense of self to are taken away or no longer fit our reality. Just as when I decided to leave my full-time job and started trying different things, my reality changed. I couldn’t define myself anymore by what I was doing, because it was many different things. It wasn’t a clear-cut title.

Even though in such circumstances we tend to refer to this feeling as being stripped of our identity, and change can feel like a contraction, it’s actually often a space of expansion. We can discover new capabilities and sources of meaning we might not have explored before. A kind of deep personal transformation happens in these cases.

Values as Your North Star

Raj Bhargava has a similar view on this. He teaches the Your Next Life Chapter class at Stanford and also founded a self-paced coaching app with a personalised AI companion called Your Next Work Chapter. In his course and app, he combines behavioural science and design thinking for purpose-driven career guidance.

I’ve had a few conversations with him, and he advocates for defining our values, which will inform our purpose and identity. It takes time to figure out our purpose; we need to give ourselves some space to experiment.

When I asked him about his journey from a seasoned tech entrepreneur in Silicon Valley to teaching and helping people find their purpose, he replied, “It took me three years to figure out my purpose for this chapter of my life.” He explored and learned different things during that time, and suggested that “you will know when you arrive at your chapter that feels just right.” He advised me to “centre your identity on your values.”

So, we can have different chapters in our lives, we change, and that’s perfectly normal.

Moving from ‘What’ I’m Doing to ‘Why’ I’m Doing It

Through these knowledgeable people, I learned that the loss of old identities is often the precondition for authentic growth. It’s in the dismantling of who we thought we were that we uncover who we can become.

So I asked myself, “What are the underlying features of what I used to do?”

In product management, we are connecting with people – users, developers, designers, other stakeholders – and also solving problems. Our goal is to create value, both for our organisation and our end-users. And personally, my goal has always been to do something purposeful through understanding why we do what we do.

I discovered that my desire to connect emotionally with people has been at the heart of my role and why I chose to build products. And, besides that, doing this in an intellectually stimulating environment with kind people is very important for me.

Product Manager is a State of Mind

Last week, I was co-organising a ProductTank meetup. We were in the lucky position to have as one of our speakers. Afterwards, we chatted in a circle, and he said, “Product manager is a state of mind, it’s a way of thinking.”

Even after he became a consultant and coach, he still referred to himself as a product manager. “That’s so true,” I thought. Questioning the status quo, focusing on creating value, collaborating with diverse people, and being curious – all these are traits we can find new ways to express when old roles fade.

Product manager is my strongest professional identity too, precisely because of the way of thinking it represents. What’s yours?

I remember, in my second product role, I was working as the sole product manager at a startup where they wanted to build a “spaceship” – a huge product with all its bells and whistles. At the time, I was reading Marty Cagan’s Inspired, and I remember thinking, “We’re doing everything wrong!”

I worked with two male founders who were very strong-willed, so it was difficult to shift their mindsets. What also didn’t help was that they had already committed to a very tight timeline with investors when I joined the company. So I “just” needed to make sure the development agency that was building the product executed on time.

I did my best to create some structure and show them how out-of-reach their plan was, and why it didn’t make sense to build everything they wanted. But I certainly could have used a more experienced product person’s perspective to craft some convincing arguments.

ended up being my mentor, of course, without her knowing it. Her actionable, practical content helped a lot in making sense of large scopes. Other product people also came to my rescue with their candid conference talks, books, and articles.

Now, years later, I’ve learned a lot about mentoring and coaching, and enjoy supporting (aspiring) product managers. It can make a big difference in someone’s life when you get a more experienced, or just a different, perspective than your own.

If you’re in product, I encourage you to mentor others; this guide aims to help you with that. If you’re looking for a mentor, this will hopefully be helpful in knowing what your responsibilities are in this process.

Subscribe now

The Modern Mentoring Mindset

I recently attended a workshop on mentoring, as I joined a program to mentor university students from my alma mater, Copenhagen Business School. One of the thoughts that stayed with me was that modern mentoring is a mutual, collaborative learning process.

Traditional mentoring was based on the assumption that the mentor knows best, thereby giving advice to the mentee. In this case, there’s a risk of creating a “cloning factory:” you end up shaping the other person to your own image. The goal with mentoring is to give the mentee the opportunity to create themselves.

This collaborative mindset truly resonated with me.

How to Be a Great Mentor

Your role as a mentor is to facilitate the mentee’s thinking and empower them to take charge of their own development and career.

When I meet people who are interested in mentoring others, their fear is often that they’re uncertain how to structure the mentoring sessions. So, let me give you some ideas here that are informed by my learnings from an executive coaching program, the mentoring workshop, and my experience in coaching and mentoring product managers.

1. Set the Terms and Define the ‘Why’

Before you dive into specifics, establish a clear collaboration model.

• Establish ground rules: Discuss frequency and length of sessions, confidentiality, and clarify expectations.

• Agree on objectives: Ask the mentee, “What is your goal for our mentoring sessions?” This might change as you collaborate, but it makes it clear what the mentee wants to achieve and how you might support them. In each upcoming session, you can start by asking a few questions to clarify what they want to work through during that specific session:

  • “What’s the subject that you want to explore today?”

  • “If you were to say it in a few words, what is your most important goal related to this topic?”

  • “Where would you like to start?”

• Challenge them (in a kind way): Once they’ve defined a goal (e.g., to get a senior product manager role), dig deeper into their motivation by asking, “What will this do for you?” This will challenge them to think deeper about their motivations, and they’ll gain new insights.

• Be authentic: Your mentee appreciates you being open and willing to share successes and failures. You don’t have to be a “perfect” professional; some vulnerability shows the mentee a more realistic approach.

2. Know Your Roles (Beyond Just ‘Advisor’)

As a mentor, you wear many hats, depending on the situation. The important thing is being aware of all these roles you can take on.

I learned these roles from Kirsten M. Poulsen, the founder and director of KMP+ House of Mentoring who have been designing professional mentoring programs for the past 25 years:

• Storyteller: Share inspirational and cautionary tales from your past. (E.g. how you handled a difficult stakeholder, or what you learned from a product flop.)

• Discussion partner: Enter into discussions and challenge mentee.

• Advisor: Provide specific, expert knowledge when truly needed. (E.g. for job interviews.)

• Knowledge sharer: Share professional knowledge when needed to guide the mentee on where to find information on different topics to make better decisions.

• Coach: Ask questions that lead to new insights. (E.g. When do you really feel you’re in flow? What changes your energy dramatically?)

• Critic: Help the mentee to ask for feedback and give it to them constructively. (E.g. What would you like to gain feedback on?)

• Networker: Support the mentee in developing and using networking; guide them how to grow their network.

• Door opener: Help the mentee gain access to new networks or contacts by opening doors to people, references, or opportunities. It’s important to note, that it’s the mentee who has to step through the door and take initiative.

• Sponsor: Guide the mentee in their career progression by advocating for and supporting them in concrete ways that build professional growth and confidence.

• Friend: Encourage and support mentee.

3. Don’t Let the Monkey Jump

During my executive coach training, our experienced coaches emphasised the importance of “not letting the monkey jump over to your shoulder.” Meaning, that it’s the coachee’s responsibility to take action. It’s the same with mentoring; the mentee is driving. They need to take ownership of their present and future, the mentor is just there to support them.

4. Review and Evaluate Collaboration

At the end of each session, you can ask the mentee to review what happened for them in the session:

• “Where are you now in relation to your goal?”

• “What are you taking away from this exploration today?”

• “What is a small step you could take?”

These questions will deepen learning for them and bridge your session with the outside world where they can act on their objectives.

You can also evaluate how you collaborate: what’s working and what needs to be improved. It gives you both the opportunity to openly share your thoughts on

• what you should keep doing in the next sessions,

• new activities you might want to add, and

• what you might want to stop doing.

So you can iterate on your collaboration based on feedback from each other, just like working on a product.

Share

How to Be a Mentee

When you’re the person being mentored, you have the full responsibility for articulating your goals. Being a mentee is not a passive activity where you wait to be educated; it requires active ownership.

Your mentor is giving you their time and experience, respect that investment with preparation and clarity.

1. Do Your Homework

Preparation is the single greatest sign of respect for your mentor’s time.

• Come with objectives: You should prepare an introduction and your objectives for the first mentoring session. Share what you want support with.

• Define your problem, and come with a proposal: When you present a challenge, frame it clearly and share your thinking. For example, “I am struggling with stakeholder alignment on feature X because of Y competing priorities. My proposed solution is Z. What blind spots am I missing?”

• Ask deeper questions: Don’t just expect solutions from your mentor. Instead of asking what career path to take, you should reflect on your motivations, explain your thought process, and display your critical thinking by asking thoughtful questions.

2. Embrace and Discuss Uncertainty

Uncertainty is a fundamental part of a product manager’s job, whether it’s market disruption, team instability, or career ambiguity.

• Be open and honest: If you’re unsure of your next move or don’t know something, don’t hide it. Discuss your reasons for uncertainty and work on addressing them so they don’t become a hindrance to your professional aspirations.

• Be active and eager: The most effective mentees are proactive. They actively seek support, tools, and new perspectives. Take notes, commit to actions, and report back on what you tried and what you learned.

3. Give Back Through Reverse Mentoring

Remember, the process is mutual. Your mentor benefits, too. By being a well-prepared mentee, you naturally offer reverse mentoring. You bring new knowledge, fresh insights on emerging trends (AI, digital tools, new user behaviours), and challenge the mentor’s established thinking. This is how the most valuable relationships are built.

Find Your Mentors and Mentees

I hope this guide has provided some inspiration to find your mentor or mentee (or both). You can always learn during the process, the important part is that you’re open to feedback and stay curious.

What often happens in large corporations is that someone – a business leader or a product manager-adjacent person – tells the product team what to build. This is communicated through quarterly iteration planning, but the reasons are typically not shared. Why are we building this? Who is the end user?

I’ve recently heard from a software engineer at a workshop I was running that they were frustrated with the user story template:

I as a [user persona]
Want to [do an action]
So that [I can achieve an outcome]

The reason for their frustration was that they didn’t know who the user was, and neither what outcome the user wanted to achieve.

That’s a bummer, because this way a user story template is really just for the template’s sake; it doesn’t make any sense.

So, ideally, how should all this work?

Before we can come up with the right solution, we need to understand the problem or need our user is having that we want to solve. The whole goal of this is that once we solve that user problem, our user will either buy our product or stay with it longer, so it ultimately generates a financial return on our investment.

But if we don’t actually succeed in solving that pain point, it won’t do anything for our user; we’ll just generate costs.

Subscribe now

Start From Your Target Audience’s Problem

We started building Little Parrot because we’ve seen that product people struggle with a couple of things:

1. A lack of time to allocate to lengthy courses to learn new skills.

2. The current tech landscape is changing so rapidly that it can feel like a full-time job to keep up.

3. Constant fear-mongering in publications and professional networks (like LinkedIn) about falling behind without knowing a ton about AI.

Ideation Workshop

Prioritised User Problem

It’s important to make sure that your whole team is on the same page about the problem you want to solve for your users; it’s not just the product manager and designer who own this knowledge. Deeply understanding the problem will result in coming up with better solutions. Since developers are the closest to the technology, they have a unique perspective on what’s possible; involving them in ideation will therefore result in better solutions.

Even thought we have a two-person team building Little Parrot, we still started from the prioritised user problem we aim to solve by filling in this template:

I am [your user]

I am trying to [desired outcome]

But [barrier / problem]

Because [root of problem]

Which makes me feel [emotions]

Here’s what it looked like in action:

I am a busy product manager

I am trying to feel confident

But I don’t even know where to start to get actual skills

Because I don’t know what the best framework or methodology to apply is and I don’t find real practical resources

Which makes me feel overwhelmed and paralysed.

We predominantly thought about the current AI hype and how overwhelming that can feel, but we didn’t want to only focus on AI skills, but broader product skills as well.

Create Your Persona

Understanding who you’re designing a solution for is essential. It helps to build empathy across your whole team.

We used a simplified way to define our persona, focusing on their main characteristic, frustrations, and goals.

This is what we came up with:

Persona: Chick

• About: busy product manager

• Frustrations:

  • there's so much to learn, so little time;

  • FOMO with constantly evolving tech landscape.

• Goals:

  • to feel confident in their job;

  • to quickly acquire applicable skills.

Chick is a character we came up with: a PM who is still learning represented by a chick still in an eggshell. Honestly, it’s partially a version of me, reflecting all the mistakes I’ve made over my product journey.

Storyboard: From Struggle to Solution

Drawing helps with communicating ideas. Visualising the user’s story helps us empathise better which then unlocks innovative solutions in us.

So, everyone in our team went through each step to create a storyboard, and we discussed what we drew after each step. This allowed us to get inspiration from each other and make sure we’re working towards the same goal.

The steps of the storyboard are the following:

1. Draw what the user struggles with.

2. Visualise what the user can do and how they feel once the struggle is resolved.

3. Sketch all the moments that lead the user from the initial struggling moment to their happy ending. Show how your solution helps them get there.

Subscribe now

Our user is struggling with:

• All the fear-mongering messages that they are behind.

• They try to use AI, but they get back generic, fluffy answers.

• As a result, they don’t understand why AI is so useful for everyone else. (Have you seen the “10x developer/PM with AI” posts on LinkedIn?)

Once the struggle is resolved:

• Chick knows what to use Al for

• Can collaborate with it

• Can prompt it to get high-quality, useful outputs

• Potentially, they can automate recurring tasks

• Feels confident with their colleagues (discussing AI)

The happy ending looks like:

• Chick understands the foundations of how AI works, so they can use it more efficiently.

• They’ve acquired prompting techniques to get high-quality, useful outputs.

How they get there:

• Little Parrot offers a nurturing, and stress-free environment where they can practice and learn, following science-backed methods for better knowledge retention.

• It’s okay to experiment and not get the answers right, because that’s how we learn: by trying things and practising.

• They can learn in bite-sized pieces (e.g. while waiting for the bus).

This allowed us to really get to the core of the solution we want to create.

Happy Building!

I hope these ideation techniques will come in handy next time your team is coming up with a solution for a new feature or product. Happy building!

I’ve been in the tech industry for over 10 years, working in a variety of roles: account management, development, product. I’ve worked at both B2B and B2C companies, big and small.

Previously, I successfully carved out MVPs for replacing legacy systems or adding a new feature to a live product. But with Little Parrot, I found myself second-guessing when we were trying to define an MVP to build and test our idea.

In this article I want to untangle why that was, and explore the dilemma of the MVP.

Try Little Parrot for Free

The Logic of an MVP

When we build a new product, there are a ton of assumptions we make. At its core, we believe it will be valuable for someone, so they will pay for it.

We are told to build fast and iterate, based on user feedback to ensure we don’t build something for a long time that ends up not solving a user’s need or problem, or fulfilling a desire. Therefore, we aim to build the smallest possible piece that can deliver core user value.

And user value is crucial, because if your potential user tries your product, and it doesn’t prove to be valuable enough, they just abandon it, and might never come back.

So this smallest possible piece needs to be incredibly valuable and preferably frictionless, since getting the attention of your target audience is also quite hard at this early stage – unless you’ve already exited from building Twitter or Slack and have a huge network to amplify your message.

Well, that isn’t the case for us. We’re still in the validation phase and we are grateful for each website visitor who enables us to learn something new. They help us to test our hypotheses and see if Little Parrot is valuable for product people.

The Contradiction of “Building Fast” and “Valuable and Frictionless”

When we talk about building fast, it’s easy to assume the first version of our product can be wonky and full of errors, as long as we get it into users’ hands quickly. You might even remember Mark Zuckerberg’s famous saying of “move fast and break things.” But “building fast” refers to the scope, not the quality of your product.

You might give your wonky and error-prone product to your trusted friends to give feedback on. Or to a group of alpha users whose expectations about the product quality is managed. But shipping something with a bad user experience to the wider public will result in lost users.

In Little Parrot’s case, we were concerned, if our initial offering was hard to try and didn’t work as our users expect it, then we’ll wrongly conclude that there’s no market need for it. When, in reality, our execution was the issue.

“Building fast” means that you should slice out the smallest possible piece of your product that can deliver core value without building all the bells and whistles of it. And the “fast” part specifically refers to the speed of getting this limited scope into users’ hands to validate whether it’s valuable for them.

“Valuable and frictionless” is about the experience of that limited scope. This is where quality comes in. If the small piece you build quickly isn’t valuable, users won’t stick around long enough for you to get meaningful feedback.

If it’s not frictionless or is full of bugs, users will get frustrated and leave. This leads to skewed validation results. We wouldn’t know if they left because the content of our micro-course wasn’t good or because the experience in the course flow was painful.

Subscribe now

Our Dilemma

We started Little Parrot by building out the landing page, then the first micro-course, and a pledge flow to test payment intent. When we had half of a micro-course ready, we wanted to get feedback on the course content. But we were wondering, does this really solve a problem or provide useful insight for our target audience, busy product people? Does it deliver on our promise of being “science-based” and “practical?”

Even if it’s just half a micro-course, it needs to leave the user feeling like they gained something significant and that their time was well spent. If it’s not valuable, they won’t come back for the next half or the next course.

Then we had to consider the frictionless part. Is the experience of accessing, consuming, and understanding that content smooth? Are there any technical glitches, confusing navigation, or unnecessary steps that would make a busy product person abandon it? Friction kills engagement, especially for an audience with limited time.

Since we were part of Lovable Shipped – a competition with the goal to build something from scratch and ship it – we had access to a community to test and give feedback on our product.

Iterate

Iteration builds on a solid core. Once you have that small, valuable, and frictionless core, you can then iterate.

First, you gather feedback on that core experience to learn about what worked, what your users liked, and what was missing, what they wished for.

Then, you build the next small, valuable, and frictionless piece based on that learning. For us, it was the second half of the course. But it could have been a new feature that might be useful in the learning experience, or a new course on a different topic.

So, for our microlearning platform, we had to make that initial half micro-course an impactful and seamless experience. That’s how we’d get the engagement and feedback necessary to guide our iterations forward.

We learned some really valuable feedback:

• Our initial users thought that the focus on microlearning and real-world prompting use cases felt highly relevant.

• People wanted to try the course before buying it, so we made the first challenge free.

• Showing too many steps overwhelmed users, so we broke the course down into challenges and displayed the steps for each specific challenge. This way our users can take a bite-sized learning challenge while their coffee brews, and come back later.

• Users wanted to see how the course looked like even before clicking away from the homepage. That’s why we added a gif to the hero section to display a couple of steps of the course.

The Takeaway

The key here is to define the absolute minimum you need to build to deliver a complete, valuable, and frictionless experience for one specific use case. This is how you make your MVP good enough to start getting meaningful feedback, even if it’s not the full vision.

Now we have a full micro-course ready called Write Better with AI: Prompting Foundations for Product Managers. Our current goal is to gather feedback on this core experience. What our users love, what they wish was different.

If you end up trying Little Parrot, we’d love to hear what worked and what could be improved. We’re still at the very beginning of this journey. Feel free to comment on this article or reach out to me on LinkedIn.

I’m curious, have you ever struggled with defining an MVP of your product or new feature?

I started by building a couple of experimental products, just to try it. After all, building a working web app with just prompting feels magical. I then spent the last three months building Little Parrot, a micro-learning platform for busy product managers. We have one micro-course so far: ‘Write Better with AI: Prompting Foundations for Product Managers’. I believe prompting is one of the most important skills for effectively using AI, and because communicating in writing is a time-consuming activity for a PM, AI can help speed it up.

I joined Lovable Shipped in June, a competition organised by Lovable to build something from idea to a live product in six weeks. Little Parrot ended up ranking number 40 globally, out of 5,800 contestants.

During Lovable Shipped, we supported each other in the community and collaborated on our products. I reviewed and provided feedback on at least ten products a week created by other builders, which exposed me to a wide range of vibe-coded apps.

Subscribe now

The Importance of Design When Vibe Coding

Building with AI has an inherent risk of being more generic and less differentiated. Large language models (LLMs) that generate the code when you build by vibe coding are prediction machines, so they predict the most likely output. Many websites I gave feedback on during Lovable Shipped practically looked the same, with identical layouts, colour gradients, and fonts. This isn’t great for building a unique brand.

This is why giving specific instructions on how your product should look and feel is essential. You don’t have to come up with a full design system, though that’s helpful, but specify your brand colours, fonts and give the AI some pointers:

“Smooth hover transitions, fade-in on scroll, soft entrance animations.”

“Soft gradients, muted palette, generous spacing, gentle transitions.”

Lovable has a full guide for inspiration.

How to Prompt Lovable

To be honest, it can be frustrating to build software by prompting. I found it’s easy to get lazy with prompting. I expected Lovable to just figure out the best way to build what I wanted, because figuring out the right user experience is hard. But AI fills in the gaps, and without specific instructions it defaults to the average.

Being specific about what you want to build is the best technique you can do.

Giving long-winded instructions might not help. Instead, structuring your prompt is your best friend when vibe coding. You can use markdown or XML tags to separate parts of your prompt. I wrote more about this in my series on practical prompting techniques. Applying these help the LLM to parse your prompt more effectively, and to “understand” what you want it to do.

Use Technical Language

I’ve found that using technical language with Lovable gets the best results. I tried prompting it in an outcome-oriented way, but at the end of the day, it’s not your developer partner.

While collaboration with a human developer works better if you give them the ‘why’ – the user problem – it’s better to be solution-focused when collaborating with AI. Tell it to build an umbrella in detail, instead of asking it to solve the problem of our user getting wet in the rain.

Giving it implementation details (frameworks, libraries, tools to use) increases the quality of their output.

I found that using Gherkin to explain to Lovable what I wanted works pretty well. Just make sure you think through all the scenarios, otherwise it might not implement all of them. Understandably so, it’s not there to come up with all the corner cases that you missed. Sometimes it follows instructions very literally.

When we were implementing discount codes on Little Parrot, I prompted it:

Scenario: Learner can remove the discount code
Given the learner added a discount code at checkout
When they click the trashcan icon next to the discount code
Then the discount disappears
And the price of the subscription reverts to the original price.

What I failed to do was specify that it should also remove the discount code from the backend and Stripe (which we use as our payment provider).

So when I was testing the flow out, I added one discount code, deleted it, then added another, and encountered an error message. So I asked Lovable:

Why couldn't I apply the "newcode" coupon? I got the "Invalid coupon code or coupon has expired" error. This coupon exists in Stripe.

The cool thing is that Lovable sees all the error logs, so it can detect what the issue is. So, it identified that the previous discount code I added, although was no longer visible on the UI, still existed on the backend:

The issue is that you already have the "testcode" coupon applied to your subscription, and the current implementation of the apply-coupon function has trouble handling multiple discounts on the same subscription.

You can use Lovable without understanding how software works, but some technical knowledge certainly helps to build a more robust product and solve issues quicker. Vibe coding is actually a great way to learn more about coding, because you can ask questions in context from the AI.

Refer to Components

To efficiently build your product, refer to components in your prompts.

By default, Lovable uses Shadcn, a UI component library. You can brows through it for components and refer to them by name: Card, badge, button, modal, input, tooltip, toggle, etc.

Specifying which page, component and UI element you want to change:

On the subscription-checkout, move the “Subscribe now” button to the Order summary component, under the Total and above the "Help us do good things"

Edit Visually

Lovable allows you to select a specific element using the visual edit functionality, so you can also make changes in a targeted way.

It helps to keep the scope of your change limited, so the AI won’t accidentally overwrite a different part of your app.

How to Fix Bugs

When you build a product, it’s inevitable that bugs happen. When you build a product with Lovable, I suggest using the chat mode to identify the root cause of the issue.

It can happen that Lovable says it fixed something, but the issue still exists. In chat mode, you can ask it to outline a plan before it writes code, then ask questions to clarify. Once you’re satisfied with its answer, you can switch back to building mode and execute the fix.

If it’s a visual issue, taking a screenshot of what’s not working, and then pasting it into Lovable can help it better identify the issue.

If you get into a bug loop and a fix is not happening, you can rollback to the last working version of your product and try to prompt the functionality again. This time you can try a different, more specific prompt with all the learnings from the bug fixing efforts.

Reframe Your Thinking

I repeatedly caught myself expecting the AI to be smarter than me and figure out a better user experience for the app. So I’d lazily give it a half-sentence prompt, expecting it to come up with something superior. Of course, it failed to “think” better than me, which reminded me that I shouldn’t outsource my thinking to AI.

We are bombarded with messages about people building a working product in an hour. These are usually the “build a CRM” or “create an Instagram clone” type of prompts.

I think that only works if you don’t care about how your product ends up working. Without a doubt, you can create something super quickly with vibe coding. But once you build something a bit more complex that needs to work in a specific way, it requires more time than an hour or a day.

And it makes sense. You need to think through how things should work. In my experience, that’s one of the hardest parts of building a product, figuring out what the exact solution should look and work like. Then you have to break it down to small pieces that you can feed to Lovable for the best results.

Even when you are very specific, it’s a good idea to test what you’ve built. With AI, it’s easy to get something that seems correct but doesn’t quite work as you intended. After each change, it’s best to test if what you wanted works as expected, because it’s easier to fix issues right away or revert your change if it went in an unexpected direction.

Go On, Try Vibe Coding

I encourage you to give vibe coding a try. Lovable has a free tier to get you started. Every day your 5 credits get replenished, so you can keep building little by little. It feels very empowering to build a working prototype or app alone. But I still believe that the best products are created by people with different viewpoints.

If you’d like to try Little Parrot to learn practical prompting techniques you can apply to your work, please do give feedback afterwards. We have many hypotheses on what to improve, but we didn’t want to perfect it until we were delighted with the result. That would just be bad product management. Even though, I admit, it’s a very vulnerable feeling to share something you feel is not perfect.

On Tuesday – the day I should have scheduled my publication – I felt completely overwhelmed. We were preparing to run a 2-hour workshop on Friday at the Copenhagen Developers Festival, and launching our experimental product, Little Parrot, on the same day.

Even though it’s now Saturday – three days past the publication day I committed to – I’m still determined to consistently improve my writing, share my thinking about building products, and experiment with different ways to engage with people.

I’m writing this on a plane from Copenhagen to Lisbon. Since I became self-employed last year, I’ve been reminded of the importance of consistency so often.

We live in an overnight-success culture. We see startups reach super high revenue over only a couple of months since launch, claims that lucrative products are built in a day with vibe coding, and content creators going viral. All these do happen, but not overnight.

What we tend to forget when looking at those stories is the consistent work that was essential to those successes.

Consistency In Building a Company

Take the example of Lovable. Currently, it’s one of the hottest European startups, and a darling of the vibe coding scene. They reached $100 million annual recurring revenue in less than a year.1 The headlines say that GPT Engineer – the initial product that turned into Lovable – acquired hundreds of paying users overnight.2

But if you look into it, you’ll discover the consistent work that preceded Lovable’s rapid growth and overnight-success status.

First, Lovable’s co-founder Anton Osika has been coding since he was a child.3 He has put countless hours into learning his craft.

Second, building a valuable network in tech was essential for his company to reach this level of success. I mean, Stewart Butterfield (co-founder of Slack), Nik Storonsky (co-founder of Revolut), and Sebastian Siemiatkowski (co-founder of Klarna) were among Lovable’s early angel investors.4 Just imagine the multiplying effect these people have.

Third, Osika was the founding engineer at Sana Labs, an AI startup where he gained valuable experience. Then went on to co-found Depict, a Y Combinator backed machine learning startup for e-commerce where he expanded his network further.

Osika cemented his reputation in the AI scene by giving talks, and organising events. Now, I’ve only organised a handful of tech meetups so far, but I can tell you, it’s a lot of work. He also has been consistently posting on LinkedIn and Twitter about the journey Lovable is on since the early days. One year ago, most of his LinkedIn posts gathered less than 100 reactions, but his most recent post has over 2,000.

He kept putting in the work for years: consistently building his skills, his network, and his influence.

And he’s not alone in reaching immense success partly because other influential people amplify his message. I heard on a podcast that Reshma Saujani, the founder of Girls Who Code was only able to launch her NGO successfully because Jack Dorsey (co-founder of Twitter and Square) backed her initiative early on.5

Saujani recalled, “At the start, I borrowed a friend’s conference room for the first program and paid for pizza for the girls on my credit card. My husband’s assistant built our first website by putting up a splash page. It was all very bootstrap. I did not walk into this on day one knowing that I would help to build a movement or having any idea that four years later we would have reached 40,000 girls in nearly every state.”6

This was possible because Saujani had taken small, consistent steps to build ties with Dorsey during her run for Congress,7 eventually convincing one of the tech world’s most famous faces to back her initiative with both his money, credibility, and activating his network.

Subscribe now

Consistency In Public Speaking

I used to be terrified of public speaking. In primary school, I remember I almost fainted once when I had to speak in front of my class. This week, I ran a workshop at a developer conference that had some unexpected elements. Over the years, I ran many workshops in companies, gave talks at meetups, and also a handful of conference talks. But this was the first workshop I ran at a conference, and I didn’t know the participants at all.

I was nervous in the days leading up to the workshop, and I wasn’t sleeping well. On the day, I got that stomach churning feeling, the one where you think you might throw up. But then the workshop started. I cheerfully greeted the attendees, and we dove in. They were nice, interested, and engaged. I felt good during the workshop; I was in a state of flow.

After it ended, I was super tired, mainly because of all the worrying that happened the days before about the culmination of the workshop, and our product launch. But I was happy I applied for this opportunity 8 months ago. And in October, I’m doing it all over again, at two other tech conferences.

All this to say is that I keep practising public speaking, challenging myself and it’s getting less uncomfortable every time I do it. No magic trick here, just consistent practice.

Remember: It “Only” Took Consistency

Next time you see an overnight success story, instead of feeling behind or inadequate, just question the headlines and the clickbait claims. Masses of people don’t magically discover a new product or a video that ends up going viral. A lot of work and many small, consistent acts go into getting a product to that magical point. But that might not be as newsworthy as sudden product-led growth.

I’ll leave you with a mindset shift from the organisational psychologist Adam Grant that has really helped me. He suggests reframing a challenge: “Instead of saying ‘I’m here to prove myself,’ say ‘I’m here to improve myself.’ It’s a learning experience.”8 I hope keeping this in mind will help with your next challenge.

So when I discovered that a junior product manager I was onboarding to our team kept making typos in our user stories, I got that feeling you get from a mosquito bite – you desperately want to scratch it, but you know it’s a bad idea.

I had this strong urge to sneak in and correct them. But then, you know, modern project management tools track who last edited an issue. So I couldn’t just keep overwriting the stories he created.

I felt a bit trapped, because I knew that this was a stickler move. Others might not even have noticed the typos, let alone been bothered by them.

I was lucky to have a leadership coach at the time, so I brought this issue to our session, as it kept annoying me.

The coach highlighted that this issue is mine, it doesn’t have anything to do with impact. Cough… Doesn’t it?! Cough. It might hinder understandability, but I let it slide.

“Listen, I have a problem with typos, do you mind if I correct them all?” she suggested I ask the junior PM. This way, I wasn’t overcorrecting, it was something I was doing for me.

She advised adding a way for the junior PM to change his mind by saying, “If it’s bothering you in the future, I’ll stop.”

“When it’s your thing, tell people it’s yours and ask people if you can correct them,” she continued, “it has to do with your level of comfort.”

So true. When we give feedback, we have to assess the reason we are giving that feedback. Is it for you, for me, or for someone else?

Subscribe now

Steps of Giving Feedback

Okay, before you think I just helicoptered above this junior product manager, I also wanted to give him constructive feedback that could actually help him to facilitate meetings more effectively.

Giving negative feedback is so hard. We want to be nice, we want others to like us – I certainly do. But without giving feedback about a behaviour that has a negative impact, nothing will change.

From the other side, receiving feedback is a gift, it’s a learning opportunity. Even though, sometimes we don’t take it that way. We get defensive, we close off, and often don’t acknowledge the truth in the critique.

I think both sides are especially difficult, because we’re not taught to give feedback in a productive way. We get personal, we criticise, we judge.

So I tried to follow the technique by the book.

Focus on the Behaviour

Give feedback on the behaviour, not the person’s character. It’s essential that you describe the situation, the action you saw or heard, instead of adding your interpretation to it.

Also, try to give feedback close to when it happened, so you both remember the details. The closer feedback comes to the actual behaviour, the stronger the learning connection is.

After our planning session, I pulled him aside. It’s always best to give feedback one-on-one, rather than in front of the team, so the person doesn't feel ostracised.

“Brian,” I started, “do you mind if I give you some feedback on the meeting facilitation today?”

“Um, sure,” he said hesitantly.

“In the planning today,” I continued, “you opened the first user story you wrote, and asked, ‘Clear?’ Then nobody responded, so you just kept going to the next one.”

It’s best to avoid generalising and using phrases like “always,” or “never.” Just stick to the facts when you describe a behaviour. Otherwise, you risk getting into an argument, because the person might highlight the one time when they’ve done the thing differently.

Share the Impact

Describing the impact highlights the relevance of the feedback. It helps with understanding why changing this behaviour matters, and creates a sense of responsibility, such as “My behaviour directly affects team clarity and efficiency.” It links the behaviour to outcomes and might motivate the person to improve.

So I tried to describe the impact as clearly as possible, “I saw that people quieted down, and nobody responded, so we might have missed important questions that later can slow the team down.”

Don’t use “you” phrases, like “You made them pause.” That’s just an opinion, and it’s subjective. He could reply, “No, I didn’t.” Then we could just bicker about it.

If I were to say, “You were too firm, and closed off the conversation,” it can feel like a judgement on his character and might trigger defensiveness that can prevent him from learning.

Understand Their Perspective

The tricky part is that we assign our own meaning to the behaviours we observe. We make assumptions based on our interpretations, and then we act based on those assumptions.

For instance, he said “Clear?” very firmly and – in my opinion – too directly, as the user story should already be clear for the team. And this is key, it was my interpretation of the situation, not the universal truth. Even though the reaction of the team made me think they didn’t appreciate the tone, and it didn’t invite conversation, it’s still not an objective observation.

In product management, we learned that making assumptions and not validating them is an unwise thing to do. So we should remember this in these tricky, feedback inducing situations.

Instead of making all these assumptions, you might want to be curious, and ask questions through an honest, open and friendly dialogue. Instead of asking, “Why did you do that?” invite reflection.

So I asked him, “How did you see this situation? What were your thoughts?”

Then just listen and acknowledge whatever the person says, by saying “I hear you,” so they feel validated. It doesn’t mean you agree with them.

Subscribe now

Facilitate Options

Social feedback, particularly criticism, activates threat detection systems in the brain. This creates a fundamental tension: while feedback is essential for learning, negative feedback can trigger defensive responses that interfere with the very learning process it’s meant to facilitate.

It’s likely you’ll get into a disagreement if you try to correct a behaviour. People tend to choose something that’s adequate to their style, so it’s better not to give corrective input on behavioural feedback.

Therefore, offering options or asking reflective questions works better than prescribing behaviour. What you can do is facilitate a conversation and, in doing so, create a learning experience with questions like, “What could we do differently next time?”

I asked him, “Looking ahead, what are some other ways you could check for understanding?”

“Huh, maybe just wait until they reply,” he said.

I didn’t give him my opinion, just prompted him, “Okay, what else?”

You can do this, until they give you a good option. Then lock that in, “That sounds good.”

At the end, I asked him, “Could I give you my opinion?” If you’d like to share a practice you’ve seen working, you can do the same.

I suggested, “Next time, you could try reading out the user story, so everyone can take the time to understand it. Then ask the team ‘What questions do you have?’ to encourage more discussion.”

He started nodding, “Okay, good idea.”

Go On, Give Your Feedback

I’m impatient, and I found that it can make it hard for me to get into the other person’s perspective when they make typos or facilitate a meeting inefficiently.

A thought-provoking podcast episode between Brené Brown and Angela Duckworth recently reminded me that “empathy is an antidote to impatience.”

So I should remember that person in front of me I’m giving feedback to is not me. It doesn’t matter how much typos irritate me, or how good facilitation looks for me. I should stay curious, find out their perspective on these topics, and how they want to get feedback.

This junior PM certainly didn’t turn into a master facilitator after this one feedback, but I’d like to think it helped him improve. Often, you have to keep giving pointers for the other person to support them grow. Just make sure they’re constructive, specific, and timely.

And in case you’d like notes on how you could improve, you can ask your team at the end of your next meeting, “What are two things I could do better in future meetings?”

But when I think of true leaders, I think of Jacinda Ardern, the former Prime Minister of New Zealand. She led her country through a pandemic with some of the world’s lowest death rates and introduced a national focus on wellbeing, not just GDP.

I also think of Melinda French Gates, who made gender equality a priority at the world’s largest private foundation. Now she focuses on accelerating social progress, and advancing women’s power and influence through her company, Pivotal Ventures.

I also think of Malala Yousafzai, the co-founder of the Malala Fund and the youngest-ever Nobel Peace Prize laureate for advocating for every girl to have access to education.

And I think of Shonda Rhimes, who built the storytelling company Shondaland and changed television by pioneering a new standard for diversity on screen through shows like Grey’s Anatomy, Scandal, and How to get away with murder.

What connects these leaders is that they lead with empathy and advocate for people-centred solutions. They are complex human-beings who don’t pretend to know everything. They admit when they're wrong and show that they value failure as a learning opportunity.

Of course, you don’t need to be a prime minister or a foundation head to be a leader. Being a leader doesn’t depend on your title, but on your actions.

Subscribe now

Product Manager as a Leader

As a product manager, you aren’t the line manager of anyone in your product team, but you are leading the team. Your teammates look to you to set direction, create structure, clearly communicate decisions, represent the team’s viewpoints with stakeholders, and ensure you’re building something valuable for your users.

You’re supposed to give constructive feedback to teammates, stakeholders, and even higher-ups. You’re expected to motivate your team, and ensure they are performing well. You’re the one who shares bad news or difficult business decisions and then handles the aftermath so the team doesn’t fall apart.

And you do all of this without authority over anyone’s salary, promotion, or professional development.

So how do you do all this? How do you lead without authority?

Building Blocks for Leading Without Authority

A couple of years ago, I joined a company where there were no product teams. There was a group of product managers, developers, and designers, but they were working in a more ad hoc way. The company had started to insource development a year before I joined, but was still working with external development agencies too.

I was supposed to improve the e-commerce flow and prepare it for a new offering. It was built on legacy third-party technology, an external development team was needed for major changes, there were performance issues, buggy behaviour, and various other problems. Each stakeholder group (marketing, finance, sales, development, etc.) had a different viewpoint of what “improving” this meant.

I had to ask for “resources” from the Head of Development to get started.

Form a Product Team

Having a team where you can start building a good culture, trust and psychological safety is essential when building a product. If you work with people from different organisational units, they could have different priorities. This makes it harder to create a sense of ownership for the product you’re building than if you’re all part of the same team.

I knew that I needed the following skills on the team: backend and frontend development, infrastructure, and design. So, by talking to the Head of Development, I managed to get the right people. Some weren’t allocated full-time to the e-commerce flow, but I still made them part of our team. I didn’t just want to assign Jira tickets to them. I wanted to involve them in discovery and figure out the right solution together.

One of the first activities I organised for this group of people was a workshop to officially form our team. There isn’t one way to work together as a team. You need to identify what each person’s expectations are, agree on working methodology and discuss the details of how you’ll collaborate.

Create Processes That Serve Your Team

“It was very humanistic, but not bad,” one of the developers told me after the team formation workshop. He referred to the part where I asked them about what they valued when building a product. Apparently, no one asked him that before.

Being curious about people’s needs and preferences is key to building a strong team. And you can create processes to support them.

Processes are tools, not goals. They should serve the team, not the other way around. Ask yourselves: What does this process do for our team? Introduce them only if they help collaboration or clarity, and avoid adding ceremonies just to tick boxes.

As you start working together, revisit if a ceremony you agreed on still makes sense. Sometimes it takes trying something to identify it’s not serving the team, or not actually needed.

Be Knowledgable in Your Field

For your team to trust and respect you, you have to be knowledgeable in your field. You have to communicate clearly, and understand your business, customers, and the craft of building products well.

So I started by mapping out the ecosystem that connected to and made up the e-commerce flow. This helped me to understand how the 14 different systems related to one another, an understanding that was crucial for making product decisions later on.

Subscribe now

Create a Blameless Culture

When you’re building software, it’s inevitable that things go wrong: production breaks, bugs surface, new features take twice as much time to build than expected. In these cases, you need to make sure that no one in your team is blamed. You work together, it’s all your shared responsibility.

I’ve recently heard a young man say he didn’t like playing team sports. After some follow-up questions, he revealed that he didn’t like playing football because “when you make mistakes, your whole team gets angry at you. And when you make a mistake in an individual sport, it’s only you who fails.”

I felt sorry for him. Obviously, his team didn’t have a good and supportive culture. And without that, it’s impossible to perform well. In order to innovate you need to take risks. Those risks sometimes turn into gold, but sometimes you fall on your face. And when the falling happens, you need an encouraging and caring team who catches you, otherwise you won’t take any risks again.

So, How Can You Create a Nourishing Culture?

Start by admitting when you make a mistake. There’s no better way to show your team it’s okay to mess up than owning your mistake when you make one. It can be hard to admit you did something wrong, but taking responsibility for it will signal to your team that you’re a solid leader. Product work is not about perfection, it’s about collaboration and resilience.

When someone else in your team makes a mistake, do try to understand why and how it happened. Make sure to do this in a blameless way. It can help if you use “we” language, rather than singling someone out. A good team culture is not about sweeping mistakes under a rug, but openly discussing them to learn something new. And that’s valuable, because next time you’ll do better.

Since I’ve been working in product, it happened several times that my team couldn’t deliver something as fast as the stakeholders expected. It proved to be more complex or something unexpected happened. In these cases, I always tried to understand from the developers on my team what caused the delay, and then I translated that technical jargon into a language a business stakeholder could easily understand.

Whenever I delivered the news, I always said that we had faced some unexpected difficulties that resulted in a longer development time. Don’t let anyone hang out to dry. Don’t single out a developer and say “Matt realised that the implementation is more complex than he expected.” You are a team working on a product and if one fails, all fail; if one succeeds, all succeed.

The work is often complicated and tough, but a nourishing team culture can make it easier to navigate through the challenges.

Encourage Ownership

During our first discussions with my developer colleagues, I quickly realised that some of their expectations were simply to “tell me what to do and leave me alone to work,” which for them meant writing code. This was the opposite of ownership.

Their approach was understandable, though. They had worked for a long time at a software agency, following a “handoff process:” they received long specifications, built what the document contained (or a version of it), and then handed it over to the client.

I don’t think this is the ideal way of building products, since it omits true collaboration. I needed their technical insights earlier in the process to come up with the best possible solutions together.

As a leader, it’s easy to feel the urge to take charge of everything, even though you’re not the expert in every topic. So, the wise thing to say is “I don’t know, what do you think?” Then listen and learn from your teammates.

Leaders so often think that their job is to always know the right answer. But real leaders are curious, so they admit what they don’t know, ask, learn, and reflect.

I showed my team I valued their perspective and counted on their expertise. In return, they took ownership of the work.

Subscribe now

Encourage Productive Disagreements

Healthy conflict requires trust. Disagreements surface better solutions, but only if people feel safe enough to voice them. Your role is to make sure debates stay about ideas, not egos.

Many organisations still reward people who have a strong opinion, instead of rewarding curiosity and openness to learn.

Celebrate Successes

Take time to celebrate successes your team achieved – small or big. Recognition builds team cohesion, elevates moral and motivation.

I found that bringing cakes to celebrate a significant release makes the team feel appreciated.

Make Space for Every Voice

Great ideas don’t always come from the loudest people. Sometimes, in a team discussion the ideas of more introverted people don’t surface, because when they summon the courage to share, someone cuts in. Then they cannot find the right time to jump in, and eventually the conversation moves on.

As a leader, it’s your responsibility to monitor the room during team discussions and make sure everyone gets a chance to add their input.

If someone is silent for a long time, ask them, “Maria, what do you think about this approach?” Be intentional that everyone’s voice and ideas are heard.

Closing Thought

Leading without authority is hard, but it’s also one of the most rewarding parts of being a product manager.

Your power doesn’t come from the ability to give a pay rise or promotion. It comes from building a foundation of trust, creating a space where people feel safe and heard, sharing ownership, and making space for people to do their best work.

Authority and title don’t make you a leader. People choosing to follow you does.

I stared at the screen, irritated.

“This is not how we build products!” I said out loud, to no one but my sofa.

It wasn’t the first time I’d seen something like this. A few days earlier, it was “Design is dead.” Last week: “The CTO role is dead.”

It’s easy to see why these posts spread. They’re punchy, they sound radical, and they tap into our collective fear of being left behind. But they also miss something fundamental: tools don’t kill roles or ways of working. Bad processes do.

Take PRDs (Product Requirement Documents). They emerged in the era of waterfall development, a time when changes were considered expensive, which led to the belief that teams needed detailed specs. The issue isn’t that PRDs exist, it’s how they’re used. Used as a document to hand off from product to design to development to communicate requirements and why we’re building something? Useless. Used as a living record of discovery and decisions that the product team made together? Valuable.

If the process of creating a PRD – or any document for that matter – reflects siloed thinking, it won’t matter whether it’s ten pages, one page, or generated by AI. It will fail its purpose of aligning people.

So instead of asking whether PRDs are dead, we should ask a different question: What’s actually slowing us down in building great products?

Subscribe now

The Real Bottleneck: Alignment, Not Speed of Development

In my experience, very few teams fail because they can’t build fast enough. What slows us down isn’t delivery, but rather a lack of alignment.

Years ago, I joined a company just after they’d pulled the plug on an expensive ERP (Enterprise Resource Planning) rollout. The developers weren’t the problem. They delivered what they were told to. The issue was that when one engineer asked five different stakeholders the same question, he got five completely different answers.

When I asked a developer who worked on this project to understand what happened, he told me, “I asked five people what needed to be done and all five told me different things.”

“There wasn’t a person who would have managed and coordinated the whole project,” another person shared with me.

No clarity. No alignment. And no one responsible for facilitating collaboration among the stakeholders and product team.

That’s the real issue in product development. Not how quickly we can spin up a prototype, but whether we actually agree on what problem we’re solving and what success looks like.

Without that shared understanding, all the speed in the world won’t help. You just end up getting to the wrong destination faster.

What AI Really Changes (and What It Doesn’t)

AI tools like Cursor, Lovable, v0 or Replit are brilliant. They’ve lowered the barrier to building something tangible, especially for non-technical people. You can go from an idea to a working prototype in hours instead of weeks. That’s a huge step forward.

But speed of execution is rarely the real constraint in product development. AI doesn’t magically align stakeholders. It doesn’t tell you which problems are worth solving. And it doesn’t give your team a shared sense of purpose.

If you already have a clear understanding of the problem, then yes, AI can help you test solutions faster. But if you don’t, AI just accelerates the chaos. You’ll generate prototypes more quickly, but they’ll still be prototypes of the wrong thing.

AI is an amazing accelerator, but it’s not a substitute for product thinking.

So What Should We Do?

If building speed isn’t the issue, then our real work is to make sure we’re building a valuable solution, and that requires more than documents or tools.

For me, it comes down to three practices I’ve seen make the biggest difference in teams:

1. Make decisions visible.
In too many projects, important choices are made in passing: a quick chat in Slack, a comment in Figma, a decision in a stakeholder meeting not everyone attended. Weeks later, half the team doesn’t know why something is being built. One way to tackle this is to instantly communicate decisions with your team (could be in your daily standup), and also to write decisions down. Not as heavy specs, but as a lightweight, living log of what was agreed and why. A single page that everyone can return to. This builds alignment without bureaucracy.

2. Invite the team into discovery.
I’ve always found that when developers join a user interview, they gain empathy you can’t capture in a Jira issue. The same goes for designers sitting in on business conversations. When the team shares the discovery work, you don’t need to work so hard on alignment later, because people were there when the insights emerged.

3. Take time to understand the problem.
There’s a natural temptation, especially with AI tools at our fingertips, to rush into solutions. “We’ll just prototype and see.” But I’ve learned the cost of jumping into the solution space too quickly: endless rework, frustrated users, wasted energy. Ensuring we understand the problem we want to solve will result in better solutions. A single workshop with your product team to align on the problem, goals, and trade-offs often saves months of building the wrong thing.

These aren’t glamorous practices. They don’t make for viral LinkedIn posts. But they are what actually keep teams focused and building together.

Not writing long specs. Not throwing documents over the wall. But creating the conditions for a team to work with focus, purpose, and shared understanding.

Closing Thought

So, are PRDs dead? Is product management dead? Not at all.

What should die are the bad habits: the siloed handoffs, the lack of alignment, the rush to ship without understanding.

AI can help us move faster, and that’s worth celebrating. But it’s up to us to make sure we’re running in the right direction. Use the speed AI gives you to go deeper into discovery, to get clearer on outcomes, and to strengthen alignment in your team.

So the next time you see a post claiming “PRDs are dead” or “PMs are obsolete,” take a breath. The specific artefacts we create matter less than how we collaborate around them, the structure we bring to problem-solving, and the product mindset we carry into every decision.

That’s the work that never goes out of fashion.

I’m curious, how are AI tools being implemented in your organisation?

During an online call with my team, I offered to hold a workshop where we could figure out how to increase our team’s morale after learning about this demotivating update. If I’m honest, I wasn’t completely certain how to structure this workshop, but I knew it was an important step to help my teammates deliver on our quarterly commitments. And it was important for me that they still find joy in their work, even in the middle of this uncertainty. They agreed to the workshop. So, we scheduled a day when we would all be in the office, so we could do it together in person.

“I’m not sure how to structure this workshop,” I confessed to my partner.

“You could talk to this guy I used to work with, he’s a pro in facilitating workshops,” he helpfully replied.

I immediately jumped on this opportunity. I thought, “I’ll take any help I can get.”

Before my call with the Workshop Guy, I prepared an outline that I thought might be useful for the session. On our call, I presented it to him. He liked it, and had several follow-up questions. What kind of change do you expect as the result of the workshop? Have you already had a session to give space to just complaining about this unfortunate situation?

He also had constructive feedback. One hour is not enough. Ten people are a lot, you’ll have to facilitate it strongly. We don’t want to create extra work with this for your team, the goal is well-being.

I came out of this call with many ideas, and a solid outline of what I could do.

Structure of a Team Well-being Workshop

What follows is the structure of the workshop I held for my team. We had a clear goal: to increase team well-being while living with the uncertainty of whether our product would be developed further in the long run.

1. Problem Space

We started the workshop with diving into the problem space. As we hadn’t had an official opportunity to vent about this situation as a team, it was important to allow space for people to share what bothered them.

So, I gave 5 minutes for this to happen, and presented them the instructions:

In pairs, share with each other what bothers you in this situation, what you find hard since the news broke. There are no rules for this section, feel free to complain, rage, vent. Each person has 2 minutes.

Then I asked each pair to leave the room and find a private space. It was important to preserve the meeting room as a solution-focused space, so the complaining had to happen outside. This helped to keep the next part of the session constructive.

2. Solution Space

After we had the opportunity to release our frustrations, we moved to something more productive.

We regrouped in the meeting room and started to focus on potential solutions. I gave the following instructions to my teammates:

Everyone reflects for 3 minutes. Think about what you, or the team, could do that makes you feel better and increases team motivation in the next 1.5 months. Imagine that you’re watching a movie of the activities we are doing that help us to feel better. What are these activities?

This enabled us to focus on solutions, instead of things that need to be solved. We left the uncertainty we couldn’t control behind and focused on things we actually had the power to do.

After this brief reflection, we moved on to sharing our ideas with the following guidance:

Everyone shares their best solution and puts it on the whiteboard. (If you have several solution suggestions, and we have time, then you can share after everyone had their turn.)

This allowed everyone to contribute. We imagined what needed to happen in the next month and a half for us to feel good while delivering on our commitments that was non-negotiable.

Once we had each idea on the whiteboard, we started to have a solution-focused discussion that concentrated on what we could actually do that is within our control to improve this situation.

Even though, I got the recommendation from the Workshop Guy to allow each of my teammate to select and own one thing that they felt improved their or the team’s well-being, I believed we needed to focus on communal solutions. I thought if we focused on fewer items that required a team effort, the individuals within the team would end up with more value. So, instead of everyone walking away with a personal action item, we together selected four next steps we together wanted to do.

Once we picked these four action items, we quickly agreed on owners and identified what needed to be done to achieve them. For instance, we needed to discuss the details of some of them, so we set specific dates and assigned who was responsible. This is a very important part of any workshop. It’s essential that the next steps are clear, we have a shared understanding of what each item means, who needs to do what, and who is responsible for each.

That’s why I like to send a summary in bullet-points (in this case via Slack) after the workshop to make sure everyone is on the same page and we have the conclusions recorded.

3. Closing Round

Before concluding the workshop, I asked everyone to name one thing they found inspiring today, so people could leave the workshop with a positive mindset. We needed to keep solution-focused and zoom in on what could work, and help in our situation.

What If People are Not Solution-focused?

It could definitely happen that your team has a hard time moving into thinking about potential solutions. In this scenario, it’s still important to acknowledge their hardships, but it’s also crucial to turn their minds towards solutions.

You could say, “I hear you. I know it’s hard. Now, let’s try to focus on potential solutions that are within our control. We can talk more about the issues in our retrospective.”

Next Steps After the Workshop

When you come up with solutions, you rarely have all the data to know they will work out well. That’s why it can be helpful to look at these solutions as experiments. So, we agreed to monitor how we feel during the upcoming weeks about these action items we came up with, and share what we were learning from them.

We also agreed that we could change our solutions any time, according to what we learned during the process. It’s good to leave flexibility and not to hold onto things that don’t work.

The Learnings

After the quarter ended, my team concluded that the improvement ideas we implemented in our daily work were successful. They helped us to be more focused, decreased the scope of our work and we managed to deliver all of our prioritised outcomes, and deploy them to production.

Even though work on our product got paused at the end of the quarter, we made lemonade out of the lemons we received from management.

“We might need to sunset the product. It’s a question of costs, and the board will decide,” one of our business stakeholders was explaining.

“When will they decide?” I asked, a sense of unease starting to form.

“We don’t know yet, but probably around the end of the quarter.”

“But we still need to deliver on our quarterly commitments,” our other business stakeholder interjected.

“But that’s over a month away,” I thought, the frustration building. “That’s too long to leave the team in this state of uncertainty. How am I going to tell them?”

I dwelt on this situation for the rest of my visit that week. It was a really tough spot to be in, and I felt the weight of the responsibility on my shoulders. How could I expect people to stay motivated and continue building something when it might all just go to waste?

At the time, I was in the lucky position to have a leadership coach through my work. So, when I got back to Lisbon, I had a session with her.

We’re not taught how to deliver bad news, even though it’s an unfortunate but inevitable part of our lives. In my coaching session, I got straight to the point.

“I’d like to change what we planned to focus on in our previous session. Something happened last week, and I’d like your advice on it.” I went on to explain the situation to her.

“You want the psychological side of giving bad news,” she concluded.

“Exactly!” I replied. I loved that she had a science-backed perspective.

Now, if you’ve ever had a coaching session, you might be raising your eyebrows. You might be thinking, “Getting advice from your coach? That’s not their job.” And you’d be right. Coaches who subscribe to the pure coaching model don’t give suggestions, but ask questions to help you find your own solution. But luckily, my coach was open to sharing her vast experience with me so I could tap into her wisdom. Honestly, I found this type of coaching more effective for me. She never gave unsolicited advice, and the suggestions she did give when I asked were always helpful.

As usual, in this situation, I got stellar advice from her on delivering bad news, which I’d like to share with you in this article. All leaders have to share bad news at some point, and doing it unprepared will only make things worse.

So, here’s the advice I got and used successfully.

Subscribe now

A Proven Formula: Brace – Hit – Hold

The advice I received gave me a simple formula to follow, which I used in that difficult moment: brace, hit, hold.

1. Brace: Communicate what’s happening immediately. So, when the time came, I said, “Guys, I have some bad news.”

2. Hit: Go straight to the point. I continued by saying, “I had a talk with Ralf, and there’s a possibility that our product won’t move forward after this quarter. It all comes down to costs. I’m ready to answer any questions you might have.”

3. Hold: Pause and give space to your team to ask questions. So, I just stopped and listened attentively.

When we deliver bad news, we have a natural urge to make things right. I know I had this urge. However, it’s important that when you deliver bad news, you don’t try to put a positive spin on it. If you sweeten bad news, people will distrust you. I saw this first-hand in a subsequent discussion when a manager tried to spin the news of our product potentially being sunsetted, telling the team to ‘look on the bright side’. After this chat, one of my teammates confided in me that he didn’t appreciate this approach, he felt that our manager tried to invalidate his feelings.

So, let your team members process the news. Don’t try to motivate them to keep working; it will look like you’re not on the same team. People have feelings, and all feelings are valid. Leave space for them to process their emotions without trying to sugar-coat the situation. As your team members start to open up, just keep saying “Yeah, I get it.” Let them work through it.

After I shared this upsetting news, my team was sad, confused, angry, and frustrated. All valid feelings. I wanted to make these feelings go away for them. But in a situation like this, it’s also important to remember that your job is not to hold your teammates’ anxiety; they will manage their own. So, I just gave them space to express their disappointments.

How to Prepare for Giving Bad News

I’m the type of person who loves to prepare for things. It just makes me more relaxed to know I’ve done all that I could. Before delivering bad news, it’s actually advised to write down what you want to say and read it on the day, instead of improvising. It’s essential that you are clear, succinct, and straight to the point. You might get nervous when you have to share the unfavourable decision with your team.

If you’re in a hybrid or remote setup, delivering the news in an online meeting makes it easier to use your notes. But it’s also perfectly fine to have your notes with you in an in-person meeting. You can just say that you’re using them as an aid to communicate the news clearly.

Keep it quick and concise, then open up the conversation.

What to Do After the Bad News

When someone receives bad news, they go through the 5 stages of grief:

• Denial

• Anger

• Bargaining

• Depression

• Acceptance

You can help your team get through this process by creating an opportunity for them to work through it together. After telling my team that our product might get discontinued at the end of the quarter, I waited a day to leave everyone space to process the information. The next day I offered to organise a workshop where we could figure out a way forward, as a team. It’s important to process the bad news together and turn it into something productive as soon as possible. Otherwise, there’s a risk that people will start to lose their motivation completely.

Subscribe now

Moving Forward

Since we were expected to deliver our quarterly commitments, it was essential to figure out how we move forward, keep our side of the contract and support each other in this period of uncertainty. If you can, it’s best for the workshop to take place in person, so you are physically together.

Hold the workshop with the aim of moving forward with this new information. During the workshop, you can identify what you need to do as a team to process the news. Then, you can figure out how to keep delivering on your commitments. It’s vital to foster a strong sense of teamwork and the belief that you will overcome this obstacle together. It’s natural for motivation to dip after such news. What’s most important is that the team continues functioning, no one resigns, and their motivation eventually picks up again.

Once you’ve crafted a strategy in the workshop, keep checking in with your team. Ask them, “This is what I see. Do we need to find different strategies to cope?” Don’t assume to have identified the ‘perfect’ solution right away.

I’m happy to share that nobody resigned from my team after this troubling news. We came up with a strategy that worked for us, held regular retrospectives to see where we could improve on our processes and in doing so, we implemented next steps that helped us work more effectively and in a better mood. We managed to deliver on our quarterly commitments, but then the product was put on hold, so most of our work over that month and a half never reached our users.

I hope this guide comes in handy the next time you need to deliver bad news. If you’re interested, I’d be happy to share exactly how I structured the workshop to help us figure out how to keep up our team’s morale.

There is a lot of chatter around “AI damaging our brains.” As with most things in life, there’s more nuance to this than the clickbait headlines and LinkedIn posts suggest. A recently published study, titled “Your Brain on ChatGPT,” received significant media coverage, and many people inflated its findings. Using AI doesn’t damage your brain, but outsourcing your thinking does make your brain lazier.

I was reading ’s commentary on this misinterpretation (his newsletter came highly recommended by ). It was particularly interesting as it offered a nuanced look at how to use AI to our advantage. The core idea was to think first, then use AI, rather than replacing our own thinking by asking ChatGPT to solve our homework, write our strategy, or create articles for us.

The prompting techniques that follow are a bit more advanced than those covered in Parts 1 and 2, designed to enhance your thinking rather than replace it.

Let’s dive in!

Subscribe now

Practical Prompting Techniques

1. Chain-of-Thought (CoT) Prompting

Tip

• Encourage the model to “think step by step” before giving its final answer.

• For complex problems, you can even structure the prompt to explicitly list out intermediate steps you want the AI to follow.

Rationale

• This mimics human reasoning and allows the AI to break down complex problems.

• It elicits reasoning in LLMs, and has shown significant performance improvements on complex reasoning tasks (e.g., arithmetic, common sense, symbolic reasoning).

Caveat: While CoT is proven to be a powerful method to improve the performance of large language models (LLMs), a recent study surfaced its limitations. Researchers found that the multi-step “thought process” the model generates doesn't necessarily represent the actual reasoning mechanism it used to arrive at its output. Therefore, the reasoning cannot be trusted blindly, we still need to exercise our critical thinking. Having said this, in the majority of the cases, this technique still improves the output of the model.

Example

Add phrases to your prompt like

“Think step by step,”

“Break this down into smaller parts,”

“First, identify the key variables, then…”

Business use cases:

“We need to plan a product rollout across 5 markets. Each market requires 3 weeks of preparation and 2 weeks of post-launch support. We have 3 teams that can work in parallel, but each team can only handle one market at a time. What's the minimum time to complete the entire rollout? Let's think through this step by step:”

“Here's a list of user feedback from the past month. Think step by step: first group related comments, then identify the core issues or requests, and finally suggest product opportunities based on them.” [Insert user feedback]

Life use cases:

“Help me plan a move to Lisbon, Portugal as an EU citizen. Step by step: 1) What do I need to research before moving? 2) What administrative processes should I keep in mind? 3) What’s the ideal timeline? 4) What should I prepare and pack in the final weeks?”

“I want to buy a new laptop, I’m based in the EU. First, walk me through the trade-offs between performance, weight, and price. Then suggest 2–3 models that balance those well.”

2. Encourage Analysis

Tip

• Prompt the model to analyse, evaluate, or compare before generating a direct answer.

Rationale

• This ties into CoT but also broader cognitive prompting techniques. Encouraging the model to engage in analytical steps before responding can lead to more insightful and accurate outputs.

Example

Business use cases:

“Analyse the pros and cons of these content management systems: Wix, WordPress, Squarespace, then provide a recommendation on which one to use for our website. We are a small design agency.”

“I would like to set up a SaaS company with only 5 people, I’m based in Germany. Where should I incorporate my company? Before giving a recommendation, analyse the tax rules and ensure it’s economically viable to set up the company, invoice our customers and pay dividend to the founders.”

Life use cases:

“I’m a product manager. I want to explore a more creative path outside of work, maybe something with writing, mentoring, or coaching. But I’m not sure how to start or whether it’s worth pursuing seriously. What are three different ways to explore this desire? Evaluate each approach in terms of time investment, clarity gained, and potential to lead to something fulfilling.”

---

“I’m choosing between two weekend routines to create more balance in my life:

Option 1: Saturday focused on errands and productivity, Sunday fully off.
Option 2: Spread tasks lightly across both days to reduce pressure.

Compare these two approaches and identify their similarities and differences in terms of mental load, rest quality, and long-term sustainability. I have two kids and a demanding job, so I need something that restores me.”

3. Encourage Self-Criticism

Tip

• Prompt the model to check its own response for mistakes or gaps, generate constructive feedback, and revise its answer based on that feedback. Then, repeat the process a couple of times if needed.

Rationale

• Self-criticism helps improve accuracy and depth. It encourages the model to “reflect” on its output, spot errors or weaknesses, and strengthen its answer iteratively. It’s similar to how people refine ideas through feedback and revision.

Example

After writing your initial prompt, and the LLM gave you an output, you can use these phrases to encourage self-criticism and improve the output:

“Now check your own response for mistakes or gaps, generate constructive feedback, and revise your answer based on that feedback.”

“Check your answer for errors or weak points. List your criticisms and rewrite your answer based on them.”

“Critique your solution thoroughly, and improve it using your own critique.”

Business use case:

“Here’s something I wrote. Can you check it for clarity, assumptions, and completeness? Then give me 2–3 suggestions to improve it, and revise the text using your own feedback.” [Attach or paste your text]

[After receiving a response]

Follow-up: “Now do a second review of your revision. Are there still any gaps or weak points?”

4. Decomposition

Tip

• Prompt the model to break down the problem into smaller parts, solve each one step by step, then combine the answers to reach a final solution.

• This is especially useful when you are setting up AI agents to complete tasks on their own, but you can also apply it when prompting AI in a chat interface. Just break the questions down, and once the AI has replied, prompt it with the next piece.

Rationale

• Complex problems often benefit from being tackled in stages.

• Decomposition mirrors how experts approach big challenges by identifying subproblems, addressing them individually, then synthesising the results for a stronger, more complete answer.

Example

Business use cases:

“This challenge feels too big to tackle in one go. Help me break it down into manageable steps so I can make progress one part at a time. The issue is that I need to build a company-wide AI education plan that’s actually useful to non-technical teams.”

[After receiving a response]

Follow-up: “Now, create a clear, detailed outline for each step, then highlight the immediate next step I need to take.”

---

“I want to write a book or a long essay about my experience in tech and leadership, but I keep stalling. Break this creative project into clear phases so I can stop treating it like one giant ‘thing’. Then help me tackle the first step in a simple, no-pressure way.”

---

“There’s growing tension between product and sales: sales keeps pushing for roadmap changes based on requests from prospects. Break this issue down into its root components. What needs to be resolved first, and in what order?”

[After receiving a response]

Follow up: “Based on the resolutions, suggest a practical and detailed plan to rebuild alignment without adding more process overhead.”

Life use cases:

“I’m just coming out of a major burnout phase and want to rebuild my energy, routine, and confidence but it feels overwhelming. Help me break this down into smaller parts. Suggest 4–5 focus areas I can work on one at a time, like physical health, mindset, routines, or identity. Then let’s start with the first one: guide me through simple, realistic steps to rebuild that area.”

---

“I’ve been feeling stuck in my relationship. We’re not in crisis, but we’ve lost connection and alignment. Help me break this into smaller areas I can reflect on or work through. Start with the first one and help me explore how I could improve that gently.”

---

“I’m in a weird in-between phase. I left a demanding job, and now I don’t know who I am without it. Can you help me break this identity shift into smaller parts to work through?”

[After receiving a response]

Follow up: “Let’s begin with the first part: how do I understand what I lost?”

+1 Iterate and Refine

Tip

• Don’t expect the perfect answer on the first try.

• Start with a simpler prompt, evaluate the output.

• Identify what’s missing or incorrect, and then add more specific instructions, examples, or constraints in subsequent prompts.

Rationale

• Prompt engineering is an empirical process. It’s often the most practical and effective way to get desired results, especially for complex tasks.

Example

“Write a LinkedIn post about what I learned from launching a product that didn’t meet its adoption goals, because we relied too heavily on stakeholder feedback, instead of doing more thorough user research.”

[After receiving a response]

“Dial down the emojis and the buzzwords. Keep the tone honest and humble. End with a short question to invite other PMs to share similar experiences.”

---

“Help me write a message to a client who keeps messaging me outside of working hours.”

[After receiving a response]

Follow-Up: “Make it clear but kind. Reinforce that I care about their work, but that I stick to working hours unless there’s an emergency. Suggest an async way to collect their questions.”

Subscribe now

One Last Tip and Let's Chat

I found the Encourage Self-Criticism technique very powerful, and I'd like to encourage you to try it after your next prompt. It quickly improves the quality of the AI replies and doesn’t require a lot of energy to remember. So, give it a shot!

I’d be intrigued to hear what techniques you use for getting better answers from LLMs. What are your experiences with prompting so far? Let’s learn from each other.

Catch up on the previous prompting techniques:

Over the past few months, I witnessed several conversations and presentations where someone (often women) referred to ChatGPT or Microsoft Copilot as “he”. We tend to automatically ascribe maleness to authority. It doesn’t matter if you self-identify as a feminist, you probably have internalised the idea that authority, especially in a technical field, is male. This article isn’t about gender inequalities and the issues that stem from patriarchal societies; it is about prompting AI. Where these two areas intersect is the inherent bias in AI's responses, which we need to be aware of. A recent scientific study showed that women consistently received lower salary suggestions from large language models (LLMs) than men for the same roles. This shows that LLMs carry residual societal stereotypes, likely learned from their training data.

It’s important to manage our expectations when interacting with AI. Therefore, in this instalment of Your Friendly Guide to AI Prompting, I’ll briefly go through how AI models work. It will be quick and handy. Then, we’ll explore four practical prompting techniques you can apply right away in your work and life.

Subscribe now

Brief Overview of How AI Models Work

First, let’s get our definitions straight.

• An AI model is a program trained on data to find patterns and produce useful outputs like text, predictions, or insights.

• Large language models are a specific type of AI model designed to process and generate human language. They are trained on vast amounts of information: articles, your social media posts, books, and other available online resources, which shape what they know and how they respond.

Now you might see why gender bias is baked into AI. These models don’t “think” like humans but recognise statistical relationships in text. They predict what word (or part of a word) is likely to come next, based on training data, not human reasoning. So, the reply you get from ChatGPT is merely based on probabilities.

They generate output that looks correct, but don’t ask for clarification or additional details when they’re uncertain. You’ve probably seen that they’re overconfident.

So, if you’re a product person wondering how to get true value from AI, here’s your mindset shift: You’re the one with the ideas, the AI helps you test and shape them faster.

The following prompting techniques will result in better AI outputs, but now that you understand how AI works, you know that you cannot omit critical thinking.

Practical Prompting Techniques

1. Specify Output Format

Tip

• Tell the AI exactly how you want the output formatted.

Rationale

• Ensures the output is directly usable for your next steps.

• Ensures that important details you need are part of the output.

Example

Business use cases:

“Format the interview notes as a markdown table with 3 columns: name of interviewee, date of interview, pain point.” [Attach or paste notes]

“Summarise the main insights in this research article in 5 bullet points.” [Attach article]

“Create a JSON array of 3 product items for a mock e-commerce site. Include: id, name, category, price, in_stock (boolean).”

“Turn each user quote into a Job-to-Be-Done statement. Use this format: ‘When [situation], I want to [motivation], so I can [expected outcome].’” [List quotes]

Life use cases:

“Write my holiday packing list to Norway in July as a checklist I can tick off.”

“Compare these three serums in a table with pros, cons, and price:” [List serums]

2. Provide Examples

Tip

• Provide a few examples of input-output pairs that demonstrate the desired task or style.

• If you want a specific style or format, include 1-3 (or more, depending on complexity) examples within your prompt that illustrate the format, tone, or specific task you want the AI to perform.

• Ensure your examples are diverse enough to cover different scenarios or variations of the task.

Rationale

• AI learns from patterns. Examples are incredibly powerful for guiding output.

Example

Business use cases:

“Here are three examples of effective cold outreach emails. Write a new one in a similar style.” [Attach or paste the examples]

---

“Tag each support ticket with 1-3 relevant labels based on the issue. Use tags like: billing, bug, feature request, account, onboarding, mobile, UX feedback, performance.

Follow the examples below:
Input: ‘I can’t log into my account after resetting my password twice.’
Output: [‘account’]

Input: ‘Is there a way to export my data? I couldn’t find that option.’
Output: [‘feature request’, ‘UX feedback’]

Input: ‘The app keeps freezing whenever I try to upload a photo on Android.’
Output: [‘bug’, ‘mobile’, ‘performance’]

Now tag the attached tickets.”
[Attach a document with support tickets]

Life use cases:

“Reframe these thoughts with a calm, self-supportive tone. Follow this pattern:

Example:
Limiting thought: I don’t have enough experience to lead this project.
Empowering reframe: I bring a unique perspective, and I’m capable of learning what I don’t yet know.

Now reframe:
1. I always mess up when I speak in meetings.
2. People won’t take me seriously if I ask questions.
3. I’m not sure I’m ready for this promotion.”

3. Break Down Complex Tasks

Tip

• If you have a long prompt, break it into smaller, manageable steps.

• Use clear separators (Markdown, XML tags, numbered lists) to distinguish between instructions, context, examples, and input data.

Rationale

• Separators help the model to parse the prompt more effectively, thereby helping it to process and adhere to all instructions.

Example

Business use cases:

## Role
You are an SEO expert. You write SEO titles and descriptions that make an article easily discoverable online.

## Rules to follow
* SEO title: The length for an SEO title is under 60 characters.
* SEO description: The length for an SEO description is between 50-160 characters.

## Good examples
<example-1>
[Give example here]
</example-1>

<example-2>
[Give example here]
</example-2>

---

### Your task
Compare the tools below for the purpose of product analytics in a mid-sized SaaS company. The output should be a table with:
– Tool name
– Strengths
– Limitations
– Price

### Tools
– Amplitude
– Mixpanel
– PostHog

---

### Task
Rewrite this explanation so it’s clear to non-technical stakeholders. Keep it concise and neutral in tone.

### Original
We migrated our user tracking from a server-side setup to a client-side implementation because the old backend pipeline was slowing things down and causing delays in reporting user events.

Life use cases:

### Instructions
Help me think through a potential career change by doing three things:
1. List 3 career paths that align with my interests
2. Suggest 1-2 steps I could take for each path
3. Highlight any skills I may already have that transfer well

### About me
– I enjoy writing, coaching, and solving problems
– I’d like more flexibility and meaning in my work
– My CV is attached with my professional background
[Attach your CV or pdf of your LinkedIn page]

4. Affirmative Directives over Negative Constraints

Tip

• Tell the AI what to do and what boundaries it needs to stay within, rather than what not to do.

Rationale

• While AI models are getting better at handling negative constraints, framing in the positive is generally more robust.

• Prevents unwanted outputs and keeps the AI focused.

Example

Business use cases:

“Write 5 user interview questions to understand why users churn after onboarding.
Make the questions open-ended and focused on behaviour. Avoid leading language by using neutral wording.”

(Note: “avoid” here is acceptable as it sets a boundary on how to do something, not what not to output.)

Life use cases:

❌ Instead of “Don’t use jargon,” try

✅ “Use simple, accessible language.”

Subscribe now

Next week: A Batch of More Advanced Prompting Techniques

I encourage you to mix and match these prompting techniques (and the ones you learned last week) for maximum benefit. Remember, AI is just doing some (complex) statistics to predict the next word based on its training data, but it doesn’t think. So, next time it gives you a suboptimal answer, instead of being frustrated at it, try adjusting your prompt with these techniques. Then take it’s output as a starting point and get your neural network to work as well!

Next week we’ll go through four more advanced prompting techniques and a bonus one.

Until then, happy practicing! 👋🏼

Last month, posted on LinkedIn that less than 10% of “How I AI” viewers on YouTube are female. Among the 105 comments on the post, many women expressed strong interest in AI, but they also raised several pain points:

• Limited time due to work and family responsibilities.

• Desire for non-technical, real-world use cases they could start using immediately.

• Asked for more asynchronous and skimmable formats, due to packed schedules.

• AI fatigue from repetitive or overwhelming content.

I get all this, especially the AI fatigue and the desire for encouraging and practical content on using AI, rather than the gaslighting posts we are bombarded with on social media. These pain points might also explain why women comprise only 22% of AI talent globally.

My goal with this article series is to give you a quick, to-the-point guide to improve your AI responses and get more value out of large language models (LLMs).

Prompting is one of the foundational and easiest ways to benefit from AI models. Prompts are the input you give the model, and they significantly affect the output. Well-structured prompts get clearer, more useful results. Think of it like a brief you’d give to an enthusiastic intern: the clearer you are, the better work you’ll get back.

So, friends, how can we produce quality prompts to get quality answers? This article aims to explain just that in a digestible format.

Practical Prompting Techniques

When I first tried ChatGPT, I was very dissatisfied with its output. I thought it was no better than just asking a random person about a certain topic. As time passed, I spent more and more time reading, watching, and listening to true experts and researchers in the AI space (not the social media fear-mongers!), and practising what I learned, which made it clear why my outputs had been subpar. I had given lazy inputs to the LLM. It was the classic “rubbish in, rubbish out” problem. Now, I’m sharing the techniques I learned that truly work and are backed by scientific research. I’m also including practical examples for work and life to inspire you on how to use these techniques.

1. Be Specific and Clear

Tip

• Be incredibly explicit about what you want. Don’t leave anything to interpretation.

• Give the AI exact heuristics to follow.

Rationale

• AI models don’t infer intent like humans do. Ambiguity leads to unpredictable or irrelevant outputs.

Example

Business use cases:

❌ “Summarise this article.” is less effective than

✅ “Summarise the following article in five sentences. Focus specifically on the main insights and what they mean for improving user engagement or retention.”

❌ “Improve this email.”

✅ “Rewrite this email to sound more friendly and approachable. Make it clear we expect a response by Friday.”

Life use cases:

❌ “Suggest a workout.”

✅ “Suggest a 20-minute home workout I can do before work, with no equipment, focusing on core strength.”

❌ “Plan my holiday.”

✅ “Plan a 4-day city break in Europe for two female friends in their 30s, with museums, good food, and some local craft shops.”

Subscribe now

2. Provide Context and Background

Tip

• Provide all necessary background information for the AI to understand the full scope of the request.

• Upload files to provide more context (e.g. company’s vision, sales data, user interview script).

Rationale

• More context leads to more informed and relevant responses, preventing generic or irrelevant answers.

Example

Business use cases:

“Given these user interview transcripts, what patterns and pain points can you identify?” [Attach or copy-paste the transcripts]

“I’m the PM for a B2B SaaS tool that helps marketing teams plan and publish content. We launched an onboarding flow 2 months ago, but our activation rate (users who connect 2+ social accounts and publish a post) is stuck at 30%. Our goal is 50% in 6 months.
Key feedback:

• New users feel overwhelmed by too many setup steps.

• They don’t see immediate value in the dashboard until they publish something.

Our capacity is limited: we can tackle 1-2 small experiments this quarter.
Attached: User journey map, recent NPS feedback, and usage data for onboarding steps.
Please suggest practical experiments to boost activation.”

Life use cases:

“Here’s what’s in my fridge. What can I cook for dinner tonight?” [Include a photo of your fridge’s contents]

“These are the topics I’m interested in: [e.g. women’s equality, product management, trans rights]. What podcasts would you recommend?”

“Based on the gift ideas I’ve already tried: [list], what’s a thoughtful birthday present for my partner?”

3. Define Persona and Role

Tip

• Tell the AI who it is and what it is expected to do.

Rationale

• Helps the AI adopt the appropriate style, vocabulary, and perspective for expressive tasks, like writing, influencing its tone, style, and knowledge base.

• This helps the AI retrieve and apply knowledge relevant to that persona.

Example

Business use cases:

“You are an experienced product leader. Your role is to help product managers improve writing effective user stories, from proper story slicing to uncovering edge cases.”

“You are a detail-oriented copy editor. Your role is to check this text for grammar, clarity, and tone, and suggest improvements.”

“You are an expert workshop facilitator. Draft an agenda for a 2-hour remote session to ideate solutions for a user pain point.”

Life use cases:

“You are a nutritionist specialising in busy professionals. Suggest quick, balanced meal ideas for a 40-year-old female person working long hours.”

“You are a supportive life coach. Your job is to help me organise my week so I can make time for fitness and family. Your approach should involve asking challenging questions.”

4. Define Tone and Style

Tip

• Set the tone and style in which the AI is expected to phrase its replies.

• Especially useful when crafting messages that need to reflect your authentic voice, rather than generic AI-generated hyperbole.

Rationale

• The role sets a style, but you can fine-tune it to match your needs better.

Example

Business use cases:

“Use informal yet articulate language that makes complex topics feel approachable. Employ strategic formatting like bullet points and bold text to highlight key points.”

“Rephrase this announcement in an upbeat but understated style without exclamation marks or dramatic adjectives.”

“You are a senior full-stack developer. Explain to me what an S3 bucket on AWS is, using simple language, like you’re explaining it to a non-technical person.”

Life use cases:

“Draft this LinkedIn post in a conversational, professional tone that feels relatable while avoiding buzzwords.”

“Write a message to my landlord about repairing the bathroom sink that’s leaking. Make it clear and polite, but firm.”

Next Week: Four More Prompting Techniques

I’d love to know how your results change with these practical prompting techniques. Try rewriting an email using the “Define Tone and Style” technique and let me know how it goes!

If you decide to apply these tips to your LinkedIn post and share your experiences with prompting, don’t forget to tag me! 😉

Subscribe to Thoughts by productkind, so you won’t miss the next batch of techniques next Wednesday.

In this concluding article, you’ll discover practical steps to help you put the strategies from the first three parts of the series into consistent practice with your team and keep improving your product development process over time. If you haven’t read the first 3 articles yet, I encourage you to do that first so you’ll have the practical techniques in your toolbox.

Mastering user stories in practice

Now that you understand the principles behind writing effective user stories, it’s time to put them into action. These aren’t just theoretical concepts, they’re practical tools designed to improve your team’s collaboration and your product’s quality.

Start small, learn fast

Begin by applying just one or two of these principles to your next sprint or iteration. You might start with:

• Discussing with your team what you intend to build, for whom, and why;

• Slicing one large story into smaller, testable pieces;

• Involving your whole team in identifying edge cases for a feature;

• Converting technical stories into end-to-end stories;

• Sparking conversations about what outcome your team wants to achieve with a set of user stories.

Don’t try to change everything at once. The goal isn’t perfection, but progress toward better understanding and collaboration.

Create your team's user story toolkit

Consider creating a simple checklist based on these principles that your team can use during refinement sessions:

1. Is this story small enough to complete in 2-3 days?

2. Does it focus on one clear user action?

3. Have we identified potential edge cases and error scenarios?

4. Is it an end-to-end slice of a functionality?

5. Are we clear about the outcome we’re trying to achieve?

6. Do we have a succinct, user-action-focused title?

Measure what matters

As you improve your user stories, watch for these positive signals:

• Fewer misunderstandings during implementation;

• Quicker feedback cycles as smaller stories get completed;

• More engaged team discussions during refinement sessions;

• Improved engagement in your team as the big picture is clear for everyone;

• Higher quality features with fewer missed edge cases.

Subscribe now

Remember: Stories are about conversations

User stories are never about creating perfect documentation. They’re about facilitating conversations between your team members. The story itself is simply a promise to have that conversation. The most elegant user story in the world is worthless if it doesn’t lead to meaningful discussion that builds shared understanding.

Now it’s your turn! Take one story from your backlog and rewrite it using these principles. Share it with your team and observe how it changes your next refinement session. The improvement in collaboration and quality will speak for itself.

Enjoy the creativity. You’ll also see when you are solving problems, rather than just implementing requirements, you can really have a positive impact on your users’ lives. And this is when building software products becomes a creative act!

I’d be really interested to hear what challenges you’ve faced when working with user stories and how you’ve overcome them. Please share in the comments or write directly to me!

Recommendation: The User Story Mapping book by Jeff Patton was extremely helpful for me in understanding the concept of user stories. The theory part of this article series is heavily inspired by that book. It’s also super useful when you need to break down complex user flows and decide what to build first by slicing out a minimum viable product (MVP).

Subscribe now

Catch up with all previous parts of “Mastering User Stories”:

In this third instalment, we'll explore how to anticipate the unexpected by

• identifying edge cases,

• implementing error handling, and

• ultimately tying all our efforts back to the fundamental goal: focusing on outcomes that drive real value.

Let’s dive in!

How to identify edge cases

Why edge cases matter

Identifying edge cases can be challenging. If we overlook them, our users might get confused when they try to do something we haven’t considered. A seamless user experience requires accounting for these unusual but important scenarios.

❌ Don’t do this

Don’t try to identify all edge cases on your own or rely solely on your designer to think of everything. This approach misses the collective wisdom of your team and often results in overlooked scenarios.

✅ Do this

Make edge case identification a team activity. Encourage your team during refinement sessions or when you’re discussing new user flows to identify scenarios where the user might not follow the ideal path. You can prompt them by asking “What if…” questions, such as “What if the user resizes the page?”

Use a checklist of common edge cases. You can create a checklist as you collect scenarios, so you don’t have to come up with the same edge cases every time. You can add new items to the list as you build other features. As a starting point, here are some edge cases that are frequently overlooked:

• Loading state: Loading information can take time, so it’s important to signal to your users that something is happening so they can wait patiently.

• Empty screen: There might be times when a user searches for something and no result appears. So, you should add an empty screen, communicating that no results were found.

• Text length due to localisation: If your product supports multiple languages, consider how a certain UI element will look in each language. For instance, German words tend to be longer than English ones, so make sure that button still looks user-friendly even with a long text.

• Long user input: It’s not just about designing for the average user like “John Smith”; also consider edge cases like “Hubert Blaine Wolfeschlegelsteinhausenbergerdorff Sr.” (an abbreviated version of the full name of a man who, at one point, held the record for the longest personal name). Ensure your product can handle data that is longer than average.

• Case-sensitivity: In certain fields, such as email addresses and discount codes, users might enter a mix of lower and uppercase letters. Recently, I couldn’t log into an online service, because I typed my email address with an initial uppercase letter when I registered. Even though, I did the same when I wanted to log in next time, I couldn’t enter. It was only after realising that the system had likely converted my email address to lowercase on their backend during registration that I could log in. If a string shouldn’t be case-sensitive, then make sure to handle that for your user consistently. Don’t make your user guess which one you expect.

• Time boundaries: Think about what happens when a time or deadline is near, such as nearing an expiration date or submitting data after time limits.

Separate edge cases into their own stories. Often, you can implement the happy case as one story, then edge cases can be separate stories, especially if your team identified many of them. This allows for better tracking and prioritisation.

Prioritise ruthlessly. It’s also important to note that not all edge cases need to be implemented. If you believe that an edge case is very unlikely to happen, then don’t spend time building for it. It’s totally okay to handle it once several users mention it as a problem.

Subscribe now

How to implement error handling

Why error handling matter

Similarly to edge cases, if we miss implementing error handling, our users will be frustrated, because they won’t understand what they did wrong, and what happened in the product. Effective error handling provides clarity when things go wrong, helping users recover gracefully.

❌ Don’t do this

Don’t delegate error handling to a single team member. Don’t outsource this thinking only to one person – your designer. Mapping out error scenarios requires input from multiple perspectives to be comprehensive and user-friendly.

✅ Do this

Collaborate with developers on technical error scenarios. Ask them, what technically could go wrong in the process. Developers have unique insights into potential failure points that might not be obvious to others.

Brainstorm user-caused errors as a team. Challenge your team to come up with error scenarios that could be caused by the user. A clickable prototype could support this thinking process, but looking at static designs while talking through the user flow also helps.

Create a comprehensive error handling checklist. Just as with edge cases, a checklist can be helpful in this scenario as well. Typical error scenarios (with their HTTP status code) include:

• An external service provider is unavailable (503);

• The server is not responding (500);

• Connectivity issue between your application and an external service due to network instability or slow response, causing a timeout before the request is fully processed (408);

• The page is not found (404);

• The user is authenticated but lacks sufficient privileges, therefore cannot access a page (403);

• The user needs to authenticate themselves to access the page (401);

• The user submits a form and receives validation errors (400) – clearly explain on the UI what you expect if you validate form fields (e.g. a phone number can only contain numbers).

Write clear, actionable error messages. Make sure that error messages clearly explain what went wrong and what the user can do to fix the issue. Avoid technical jargon in user-facing error messages.

Why focus on outcomes, rather than outputs

Have you ever found your product team churning out features, only to wonder if they’re truly making a difference? This often happens when we get too caught up in outputs instead of focusing on outcomes.

An output is a tangible deliverable your team produces. Think of it as the “stuff” you ship: a new feature, a line of code, a design, or any completed piece of work. For example, building a new search bar is an output.

An outcome, on the other hand, is a measurable change in user behaviour that happens within your product. This change should ultimately lead to increased business value. So, while the search bar itself is an output, an outcome might be an increase in users successfully finding what they're looking for, leading to more purchases. It’s about the impact your work has.

What’s important to remember is that your user can achieve a certain outcome in several different ways. There isn't one fixed solution. So, the ultimate goal isn’t simply to build more software faster; it’s to maximise the outcome and impact you get from what you choose to build.

The risk of fixating on outputs

Since we’re talking about features, it’s easy to forget what value our users will realise as a result of using that functionality. But features don’t automatically create value. By focusing too much on outputs, we risk neither creating user value, nor a positive business impact. Just because our feature is live, it’s not guaranteed our users will find it valuable and actually use it.

❌ Don’t do this

Avoid metrics that only track output. Avoid fixating on delivery speed, burn down charts, and how much output your team can produce at the expense of measuring the value they create.

Move away from thinking about requirements. A particular solution is not a “requirement”, it’s a possibility. We are discussing between product managers, designers and developers (and other roles in the product team if you have them) to come up with valuable solutions together that we decide to build. All viewpoints in the product team are useful, therefore involve your team members in the solution ideation process – and potentially already at the problem discovery phase.

✅ Do this

Focus on the value you create. Always ask yourself and your team, “What is the value this change/feature/implementation will deliver?” It can be value for your users, business or team. What’s important is questioning whether something needs to be done. There is always more to build, than you have time, people or money for. Always. So, prioritise ruthlessly by asking the value of each backlog item you decide to work on.

Recognise different types of value. Refactoring a functionality can also serve value if, as a result, your team will be able to deliver more efficiently, even if your users don’t realise immediate benefits.

Challenge new ideas with problem statements. When a “cool, new idea” surfaces during your team discussion or stakeholder meeting, always ask yourself and your team “What (user) problem are we solving by implementing this?”

Measure outcomes after shipping. Once you’ve built and shipped a new feature, measure if it actually proved to be valuable. How did your users’ behaviour change? Are they completing an action quicker now? Are they able to achieve something they weren’t before? This can be measured in qualitative ways, e.g., via in-product survey or by the number and content of support tickets that concern that topic. Also, by quantitative ways in your product analytics, looking at how many people use that new feature or if the retention or funnel completion metrics improved.

Subscribe now

Putting it into practice

By diligently identifying edge cases, implementing thoughtful error handling, and consistently prioritising outcomes over mere outputs, you’ll elevate your user stories from simple descriptions to powerful tools for building products that truly deliver value and a seamless user experience. Don’t feel you need to perfect everything at once; try making edge case identification a team activity, or ensure your next error message is clear and actionable.

In our final article of this series, Part 4, we’ll bring all these principles together, offering practical steps to embed them into your team’s workflow and measure the tangible improvements in your product development process.

Catch up with Parts 1 and 2 of “Mastering User Stories”: