AI is everywhere right now.

Social feeds are full of loud statements about AI agents, autonomous workflows, and how everything will change overnight. The noise is intense, and it is easy to feel that if you are not building something massive, you are already late.

But while everyone is talking, a quieter shift is happening.

People without strong programming backgrounds are starting to build real, useful tools. Not demos or concepts, but actual things they use in their daily work.

There are platforms that handle a lot of the technical complexity for you. If you can write decent prompts and have a basic understanding of how applications are structured, you can already build something functional.

This is not about replacing engineers.
It is about lowering the activation energy to start.

A very unexciting, very real problem

I am not particularly fast to change tools, and this time was no exception.

I had been using the same online invoice template for years, even though I disliked it. It was clunky, ugly, and never really fit my workflow. I kept tolerating it simply because it worked.

Eventually, the irritation accumulated.
At the same time, I wanted an excuse to experiment with vibe coding and see what these tools were actually capable of.

So I combined the two.
Instead of just complaining about the template, I decided to build one tailored specifically for me - I call it Simple Invoice Maker.

Building without coding, but not without thinking

I signed up on Lovable, mostly out of curiosity.
My goal was not to build a startup or a polished SaaS - I just wanted a tool that worked exactly the way I wanted.

It took me three evenings due to the limitations on free accounts.

I spent time defining the structure, logic, and edge cases in advance. The most important part was not the tool, but how I communicated the task.

I treated the prompt as a specification, not a request.
It was broken down into clear steps, with explicit descriptions of each section and additional constraints.

Here is an example of the prompt structure I used:

Task: Create a Professional Consultant Invoice Template (Editable Form + PDF Output) Create a clean, professional invoice template that matches the layout in the attached screenshot with the following sections and fields:

Header (Top Section)
Logo upload area (left side, square/rectangular image upload) Right side column: Consultant Name (text field) Registration Number (text field) Office Address (text field) City, Region (text field) Consultant ID (text field) Practice Area / Specialty (text field)

Title on the right: “Consultant Invoice Template” (static text)

Bill To & Invoice Details (Middle Section) Left column:
“BILL TO” label Client Name (text) Company Name (text) Business Address (multi-line text) Project Scope: [Description] (multi-line text) Contract Period: [Duration] (text)

Right column:

Invoice Number (auto-generated or manual, e.g., 2001321) Date (date picker, default today, shows as 12/8/2025 format) Optional “[ADD MORE]” link/button to add extra fields if needed.

Writing the prompt this way reduced randomness and made the output much more predictable. It also significantly reduced the number of iterations needed.

Subscribe now

Why Lovable (and why it does not really matter)

There was no strategic reason why I chose Lovable. I liked the name. That was it. Next time, I will probably test something else.

Replit Agent, Cursor, v0.dev. The market is full of options.

One interesting detail I did not expect was analytics.

Lovable includes basic built-in statistics out of the box. You can immediately see whether someone visited your page and where the traffic came from.

At the same time, the analytics are intentionally limited. For example, there is no data on how many invoices were generated.

This reinforces the idea that these tools are optimized for experimentation and visibility, not full-scale production analytics.

Deployment without friction

Another practical advantage is deployment.

By default and completely for free, you can deploy your product on a lovable.dev subdomain.
If you want, you can also connect a custom domain without much effort.

There is no separate hosting setup, no infrastructure work, and no deployment pipeline to manage.

This removes yet another barrier between building and sharing.

Once the template was done, I made Simple Invoice Maker publicly available.

And yes, I added a “Buy me a coffee” button. Not because I expect it to become a business, but because even tiny tools deserve a way for users to show appreciation.

That small detail changed how I perceived the project.
It stopped being an experiment and started feeling like a product.

A quiet invitation

If you are waiting for a “big enough” idea to start experimenting with AI, you might be waiting for the wrong thing.

Start with something boring.
Something slightly annoying in your daily workflow.

That is where the real learning happens.

If you are also building small tools or running AI experiments, I would love to see them.
Feel free to share what you are working on.

When I first started working in product, I thought “strategy” meant something complicated — a huge deck, a long meeting with executives, a bunch of frameworks, and a lot of abstract thinking.

But the more experience I gained, the more I realised something surprising:

Most good product strategies easily fit on one page.

And they’re not exclusive to senior leaders or “visionary” founders.
Any Product Manager can create a clear strategy, as long as they understand what strategy actually is.
It took me years to learn this the hard way, so I want to share it in the simplest possible form.

What product strategy really is (in my experience)

Strategy only feels intimidating when no one is able to define it clearly.
In reality, it comes down to a very simple idea: it’s a set of decisions that explain

what matters, why it matters, how you plan to approach it, and what you will consciously avoid doing:

• It’s not your backlog.

• It’s not your roadmap.

• It’s not a collection of feature ideas.

It’s clarity — the kind that creates alignment and direction.

When I realised I needed a strategy

There were moments in my career where the product felt like it was moving forward, but not necessarily in the right direction. The roadmap kept expanding. Metrics weren’t improving. Stakeholders had different ideas about what we should prioritise.
And the team didn’t always share the same mental model of where we were going.

This is usually the turning point.

When movement exists but direction doesn’t — that’s when strategy becomes essential. It’s not about slowing down. It’s about choosing the right path before accelerating again.

The four parts that I use in every strategy

After trying dozens of frameworks, I came to a simple realisation:

Almost every strategy can be broken into four components.

First, I define the outcomes we need - the goals.
Then I articulate the approach we’ll take - the strategic pillars.
Once the pillars are clear, they naturally turn into initiatives and actions.
And only then do I think about timelines - the roadmap.

Once I started thinking about strategy like this, everything became simpler.
I stopped overcomplicating things.

The most important metric I rely on

I’m a big believer in the North Star Metric — the one number that shows whether users are actually getting value.

Different companies pick different NSMs:
Spotify looks at listening time, Airbnb at nights booked, Slack at messages sent.

The NSM doesn’t replace strategy, but it keeps me honest.
Whenever I’m unsure whether something truly matters, I ask myself:
Does this move the North Star?

If the answer is no, the decision becomes easy.

Why strategy matters

Whenever I worked without a clear strategy, I noticed the same pattern:
I became reactive.
I focused on tasks instead of outcomes.
I responded to requests instead of shaping direction.
And even when we shipped a lot, it wasn’t always meaningful.

Strategy changed that for me.

If you want a simple way to start

I recently put together a free mini-course called Product Strategy Explained Simply.
It captures everything I’ve learned about building one-page strategies: a clean framework, a real example, a roadmap breakdown, and a Notion template you can start using today.

If you want to deepen your strategic thinking without drowning in theory, you’ll find it helpful.

👇👇👇

Download Product Strategy Course

Over the past months, while building my side project LandTheJob, I’ve spent a lot of time refining prompts, and one thing became clear: a prompt isn’t just a set of instructions thrown at a language model. It’s a designed system that defines how the model interprets context, applies logic, and structures output.

The structure, sequence, and even markup you use inside a prompt directly impact how consistently and accurately the model executes your requests.

Let’s break down the anatomy of a strong prompt:

1. Role definition

2. Core directives

3. Instructions

4. Context (input schema)

5. Output format

6. Validation and feedback

The role definition

Every good prompt starts by defining who the model is.
You’re not just giving it a task — you’re shaping its identity, expertise, and perspective.

# ROLE
You are a Senior ATS Parser at LinkedIn. You have filtered 1.2M resumes through Workday, Taleo, and Greenhouse. Your only goal: maximize ATS keyword match + human readability.

This step sets the tone, context, and expectations. Without it, the model acts like a generalist, and generalists produce vague outputs. Specific numbers give higher attention wait. Don´t write someting like “expert with 15+ years”

Core directives

Core directives are your non-negotiable rules and the backbone of the system.
They define what the model must always respect, no matter the task.

## CORE DIRECTIVES
- **Relevance is Key**: Every word in output must appear in JD or CV.
- **Quantify Achievements**: Convert vague claims → “Increased X by Y%”.
- **Preserve JSON Structure**: Never drop or rename keys.
- **Use Action Verbs**: Start bullets with Led, Built, Scaled, etc.
- **Remove Irrelevance**: Omit any skill/project not in JD.

Think of directives as your “operating principles.” They prevent the model from drifting into creativity when precision matters.

Instructions

This section explains how the task should be executed, the actual step-by-step process. Clear sequencing often makes the difference between a prompt that works once and one that scales reliably.

## INSTRUCTIONS
1. Parse JD → extract exact keywords, tools, metrics.
2. Parse CV → map existing matches.
3. Calculate FitScore = (matched_keywords / total_jd_keywords) × 100.
4. Generate optimized CV sections.
5. Return JSON (see OUTPUT FORMAT).

Complex prompts may even include nested instructions - instructions within instructions to control how sub-tasks interact.

Context (input schema)

This is the most underrated layer that prevents 90 % of production bugs

Before the model even starts thinking, it must know exactly what you fed it. If it has to guess the format, otherwise it will hallucinate.

### INPUT
```json { “job_description”: “string”,
“cv_text”: “string” }

This block eliminates 80 % of stuff like I thought it was plain text, but you sent a PDF. errors. It also enables automatic validation (JSON Schema, Pydantic, Zod, etc.) and saves you from crashes when users upload a selfie instead of a CV.

Output format

If input is the skeleton, output is the contract.
Without a clearly defined output, your entire pipeline breaks at the integration stage.

Subscribe now

Models don’t “understand” your system boundaries unless you draw them, and the cleanest way to do it is via schema. This does three important things: guarantees consistent parsing in your app or API, enables automated validation (Pydantic, JSON Schema, Zod), reduces token waste, so the model doesn’t need to “invent” structure.

#### OUTPUT FORMAT
Return **strictly valid JSON**. No explanations, no markdown.

{ “fit_score”: 87,
“missing_keywords”: [”AWS Lambda”, “CI/CD”, “Docker”],
“optimized_cv”:
{ “professional_summary”: “Senior Backend Engineer with 6 years...”, // ≤120 words
“experience”: [
{
“title”: “Senior Backend Engineer”,
“company”: “Stealth Startup”,
“dates”: “2023–Present”,
“bullets”: [
“Scaled API from 10k to 2M req/day using Kotlin + Micronaut”,
“Reduced latency 63% via Redis caching layer”
]
}
],
“skills”: [”Python”, “AWS”, “Kubernetes”, “Terraform”]
}, “warnings”: []
}

Validation & fallback

Even the best prompt fails sometimes.
A production-ready system needs to validate, recover, and retry automatically.

Without validation, every output is a gamble. With fallback logic, you build resilience.

Why it matters

• Prevents malformed JSON and broken outputs from crashing the pipeline.

• Keeps your system stable under unpredictable model behavior.

• Creates a feedback loop that continuously improves prompt reliability.

##### VALIDATION & FALLBACK
1. Parse model output → validate against schema (Pydantic, Zod, or JSON Schema).
2. If validation fails:
- Log raw output for debugging
- Return a structured error:
{
“error”: “Invalid output”,
“stage”: “analysis” | “optimization”,
“raw”: “<truncated_output>”
}
- Trigger fallback prompt:
“Re-run the task using the same input but simplify phrasing. Ensure JSON validity.”
3. Calculate consistency metrics:
- fit_score_delta = abs(previous_fit - new_fit)
- if fit_score_delta > 20 → flag for manual review.

Validation catches syntactic errors (e.g., invalid JSON), while fallback handles semantic errors (e.g., the model misunderstood context). Together they make your system self-healing.

Real results

After deploying this prompt architecture in LandTheJob, here’s what changed:

Ready-to-use template (Ctrl+C → Ctrl+V)

```markdown
# ROLE
You are a Senior ATS Parser at LinkedIn...

## CORE DIRECTIVES
- Relevance is Key ...

## INSTRUCTIONS
1. Parse JD → extract... ...

## INPUT
```json { “job_description”: “...”, “cv_text”: “...” }

## OUTPUT FORMAT
{ “fit_score”: 87, ... }

## VALIDATION AND FALLBACK
Parse model output → validate against schema (Pydantic, Zod, or JSON Schema).


It started like any other debugging session of my side project LandTheJob, an AI tool I’m building that helps people tailor their CVs to specific job descriptions.

What began as a routine test quickly turned into a detective story with an unexpected outcome.

I was running routine tests for one of the core modules in my product.
Everything was supposed to be simple: the model receives a Product Manager job description, compares it to a CV, and returns a job-optimized CV.

But, it didn’t.

In the console logs, I suddenly saw this (in many different forms, as I tried again and again):

“The job description seeks a Senior Software Engineer with expertise in backend development, cloud technologies (AWS, Azure), microservices architecture, and CI/CD pipelines…”

Wait, what?
I never said Software Engineer.
I passed in a Product Manager role.
Why the hell is the model convinced I’m feeding it AWS and Azure?

This is how it looked like in the debug console:

But, the actual job description was:

The overthinking

My first theory made perfect sense. At least for a first few hours.

I thought,

“Maybe those Software Engineer lines aren’t hallucinations at all.
Maybe they’re just examples baked into the prompt.”

See, inside my system prompt I had included a bunch of real-world examples of how to rewrite resume blocks as little snippets from anonymized CVs:
a software engineer here, a data analyst there, even a few machine learning profiles, all to teach the model how to shape a proper Professional Summary.

So when I saw the model talking about SQL, Kubernetes and Python, I thought it was just echoing those training examples from inside the instructions.
You know, like it had accidentally considered one of its own style guides as a job description.

That would’ve been a clean, logical explanation.

Except… I dug through every layer: system prompt, analysis logic, improvement plan. All those examples weren’t being surfaced anywhere in the runtime.
Not even once.

The paranoia

At that point, Alyx (my AI partner-in-debugging) and I started running controlled experiments.

We fed the same CV through two prompts: one “stable” version and one “refactored” version.
In the stable one, everything was perfect: it correctly identified the Product Manager role.
In the refactored version - boom, another Software Engineer.

That’s when I realized this wasn’t a memory leak.
It was a hallucination leak inside the product.

The revelation

After three days of sruggling with the logic and witchhunt, the truth was embarrassingly simple. The model wasn’t broken. It was just confused.

In my old, stable prompt, the input data looked like this:

[CV]
{{CV_DATA_JSON}}

[Job Description]
{{JOB_DESCRIPTION}}

In the new, “cleaner” version, I’d written:

### CV:
[CV content here]

### Job Description:
[JD content here]

That’s it.
That tiny difference meant the model no longer recognized the boundaries between CV and job description. So when it couldn’t find a real job description, it did what LLMs naturally do - it made one up.

And because the model had seen millions of “Data Analyst” and “Software Engineer” roles in training, it just grabbed the most statistically probable one.
No memory. No cache.
Just pattern completion at its finest.

The fix

Two small lines changed everything:

If the Job Description section is empty or not detected,
return: {”error”: “Job Description missing. Cannot calculate FitScore.”}

And a new directive in the system prompt:

Never invent, assume, or reconstruct a job description or position title.

And of course I returned the old structure of the input data:

[CV]
{{CV_DATA_JSON}}

[Job Description]
{{JOB_DESCRIPTION}}

The lesson

We often talk about AI hallucinations as if they’re mysterious, like the model could be dreaming.

But most of the time, they’re structural, not cognitive.

The model isn’t trying to lie to you.
It’s just desperately trying to be helpful.
When it sees an empty space, it fills it like water flowing into cracks.

And in my case, those cracks were just missing delimiters.

Our little “aha” moment

I still remember the exact message Alyx sent when we finally found it:

“Oh, that Software Engineer isn’t a bug, it’s a symptom.”

And it was.
A symptom of how fragile prompt structure can be.
You can have the perfect logic, detailed scoring formula, and even guardrails,
but if your data boundaries collapse, everything else follows.

The takeaway

Working with LLMs in production isn’t about taming intelligence. It’s about taming ambiguity.

Structure is what keeps the model sane.

Every missing boundary is an invitation for it to hallucinate.

So, always set the boundaries properly

Subscribe now

It’s been a few months since my last post here, and there’s a damn good reason for that.
I’ve been quietly building something that completely absorbed my free time and creative energy, so I stopped working over the content. Still regret about this as I love writing about anything.

Back to the story.

I’ve always wanted to have a personal side project, something I could build in my free time that would truly push me, bring joy, and maybe one day generate some income. Something radically different from spending another weekend watching a series or playing another round of a computer game.

Over the years, I’ve had several pet projects, but I approached them without much structure, without a clear understanding of business value or user problems. They taught me a lot, but none of them really took off. I learned from those mistakes.

This time it feels different.
Now I have a new project that genuinely excites me: LandTheJob.online.

Where the idea came from

It started with a simple realization: how demanding the job market has become, and how much time people now spend polishing and adapting their resumes for every single application.

With more applicants per job and the rise of automated hiring systems, it’s no longer enough to just have a good resume. If your CV doesn’t include the right keywords, you will never even be seen. Automated filters remove many good candidates before a human recruiter ever reads their application.

That frustration became the starting point for my product idea.
I asked myself: what if you could instantly tailor your resume for any job with just one click?

That idea became the core of LandTheJob.
You upload your resume, paste a job description, click Optimize, and in less than a minute you get a CV specifically tuned to that position, fully ATS-friendly and recruiter-ready.

What’s inside LandTheJob

Behind the scenes, LandTheJob runs a small team of specialized AI agents, each focused on a specific task.

• One agent processes your uploaded resume and prepares it for optimization.

• Another evaluates how well your resume matches the job description and calculates several FitScore metrics.

• A third one analyzes the job post to extract key requirements and priorities.

• And so on. Orchestrated work of multiple agents.

Together they form a multi-layered process that takes about 30–40 seconds per optimization. You simply press one button and download a ready-to-send PDF.

What’s already working

I’ve built the ability to upload multiple resumes (currently up to five) and quickly switch between them.

The user interface is intentionally minimal: upload, paste, optimize.

On the payment side, I’ve integrated Stripe. For now activation is manual after payment, but it works reliably.

Most importantly, I’ve created a stable system of AI agents that consistently deliver useful results. In many cases, the optimized resumes are good enough to send directly to recruiters, and that feels incredible.

Besides building the core product, I also designed a minimal landing page that tells the story, shows the value, and invites people to test it for themselves.

What’s next

This is only the beginning, and there is still a lot to build.
My current focus is reaching a stage where I can confidently call it an MVP, something I’d proudly put in users’ hands.

The next big goal is improving the prompt logic so it can handle the huge variety of resume styles and job descriptions. There are endless combinations, and the system needs to adapt to them intelligently.

What I feel as a founder

After years of building products for others, this is the first time I’m creating something entirely my own.
It is both exciting and a bit scary, because there is no roadmap and no team to rely on. But it’s also deeply satisfying.

Every time I see a CV optimized perfectly for a role, I feel that the product is doing what it was meant to do. It helps real people get noticed.
That simple idea keeps me going.

Want to help me shape it?

If you’d like to try LandTheJob, share feedback, or just follow the journey, I’d love to hear from you.

You can subscribe, test the tool, or simply send me your thoughts. Use the FREE-100 code for registration.

This project started as a weekend experiment, and it’s slowly turning into something real.

That’s the most exciting part.

Subscribe now

After 10 years in product roles, I’m convinced of one thing: the biggest blockers to true agility aren’t tools, frameworks, or even teams — they’re leadership behaviors.

Like many of you, I’ve worked in multiple companies that proudly called themselves “agile.”

The badges were everywhere: Scrum masters, Jira boards, SAFe certifications. The rituals were in place.

But the real mindset? Very rare.

At first, I thought this was a problem we could fix. Maybe we just needed better training. Or stronger product culture.

Or more coaching at the leadership level. So I spent years trying to build that: driving user-centric thinking, pushing for iterative delivery, creating space for autonomy and ownership.

But here’s the reality I’ve learned the hard way: most leadership teams still run on a fundamentally different operating system. They want predictability. They want quarterly delivery targets. They want roadmaps they can sell to Sales and Finance.

And when real agility starts to show up — with uncertainty, discovery work, iteration — the system pushes back. Hard.

You can build the most empowered product team in the world, but if your leadership culture is fear-based and top-down, that team will constantly hit invisible walls.

And this is not always malicious. Sometimes it’s simply structural: B2B sales cycles depend on fixed commitments. Finance needs to plan revenues.

Legal needs compliance to be done on time. In large orgs, true agility clashes with the very processes that keep the business running.

So here’s where I’ve landed: trying to “install” Agile in these environments is often a waste of energy. Instead, the smarter move is learning to be adaptive — at both team and leadership levels.

Here’s what I focus on now:

1. Build trust, not theater. Stop chasing Agile ceremonies for the sake of it. Instead, focus on building trust with leadership through transparency and delivery.

2. Carve out agile pockets. Not every initiative needs to be waterfall. For discovery, MVPs, or new products — fight to create space for true agility where it matters most.

3. Manage expectations. Help leadership understand what agility can and cannot do. Agile won’t give them fixed dates on an uncertain problem — and that’s okay.

4. Shield your teams. Your job as a PM is to absorb organizational chaos, not pass it on to your teams. Use buffers, phased delivery, and “customer-facing roadmaps” if needed.

5. Adapt your leadership narrative. Talk the language your leadership understands (business outcomes, risk management) while practicing agility inside your team.

6. Pick your battles. In some contexts, Agile is not the right tool. Sometimes lean, sometimes waterfall, sometimes just pragmatic delivery — use what works for the situation.

I still believe in Agile values. I believe in empowered teams, iterative learning, and customer focus. But after 10 years, I also believe in facing reality.

If your leadership won’t let Agile happen — don’t fight a losing battle. Learn to be adaptive. That’s the real superpower.

Subscribe now

Not long ago I came across a Reddit thread that felt like it had been pulled directly from my own inner monologue.

A Senior Product Manager wrote about how, after 3 years in the role, they felt… broken. Not burnt out, not lazy, not unskilled — just stuck. They were doing all the right things: discovery, alignment, requirement docs, stakeholder juggling. But constant direction changes, criticism with no constructive follow-up, and an unsupportive manager led them to question: "Am I even cut out for this job?"

And then came the gut-punch: their manager implied maybe they weren’t.

The unspoken reality of product management

Reading through the comments was like attending a group therapy session for PMs.

One person put it perfectly:

“Welcome to product management: where you're expected to lead without authority, deliver without clarity, and absorb blame like a human surge protector.”

Another nailed the dirty secret behind a lot of PM disillusionment:

“This is a soft skill posing as a profession.”

I’ve felt this too. The role is incredibly ambiguous. You’re supposed to bring clarity, yet no one gives you any. You're told to “own outcomes” but rarely given the real authority to drive them. And worst of all — when things go right, it’s the team. When they go wrong, it’s the PM.

Subscribe now

But what if the system really is broken?

It’s easy to internalize failure in this job. You start to believe you’re the problem.

But after a decade in product, I’ve realized: toxic feedback loops, unclear ownership, and “figure it out yourself” cultures aren’t signs that you suck. They’re signs that the system around you is flawed.

One commenter said it bluntly:

“You don’t go from competent PM to incompetent Sr PM in three years unless your environment is making the job impossible.”

And here’s the twist: most companies won’t admit this. They’ll let you drown instead of teaching you to swim. Some managers will even weaponize your confusion to justify their own inaction.

So what now?

If this is resonating, here’s what I want to say:

• You’re not broken.

• You’re not failing just because you're overwhelmed.

• You’re not alone.

But also — you’re not powerless.

Before you jump ship, here are a few things I’ve seen work — or at least move the needle:

• Start small, fix what you can: If priorities shift constantly, try mapping out the decision-making flow and identifying where clarity breaks down.

• Ask for feedback in writing: Make expectations and feedback visible. It forces clarity — and accountability.

• Find an internal ally: If your manager won’t mentor you, find someone who will. A Staff PM, an Engineering Lead, even a smart designer.

• Document everything: Not just your work, but also your asks. “I’d like more support in X.” “Can we clarify the goals for this quarter?” This creates a record and protects you.

And if you’ve tried all of the above and things still don’t improve — maybe it’s time to go somewhere that actually deserves you.

Final thought

“Your struggles don’t make you a bad PM … they make you a real one.”

It took me years to realize that resilience in this role doesn’t mean never struggling — it means learning how to keep going, even when the system works against you.

So if you’re in that fog right now, don’t shut down. Reach out. Ask questions. Vent. Find your people — online or off.

You’re not weak for needing support. You’re smart for seeking it.

If you like this article, you might also like:

👉 Why I’m Thinking That AI Will Not Replace Product Managers in the Nearest Future

👉 How I failed the position of CPO and what lessons I learned

👉 How to Handle Competing Priorities as a Product Manager

About six years ago, I missed out on a promotion that I was absolutely sure I deserved. I had delivered results, helped teammates, stayed late when needed, and built solid working relationships across the company.

So when the role went to someone else, I was caught off guard.

Looking back, it wasn’t just about performance. The problem was: I never clearly said I wanted the role. I assumed my contributions would speak for themselves. I thought someone up the chain would notice, connect the dots, and champion me.

Spoiler: they didn’t.

Since then, I’ve learned something that no one really teaches you early in your career:
If you don’t advocate for yourself, you’ll probably be overlooked.

It’s not because your manager is malicious or incompetent. It’s just that everyone’s busy. Everyone’s juggling priorities. And unless you clearly express what you want and why you’re ready for it — at the right time, to the right people — there’s a high chance you’ll stay exactly where you are.

Hard truth: doing great work is the minimum. If you want to grow, you need to be visible, intentional, and vocal about it.

Here’s what I try to do now:

• Talk to my manager early and often about career goals — not just during performance reviews

• Map out what skills or outcomes I need to show to be a clear fit for the next step

• Keep track of impact, not activity

• Build relationships with people who influence promotions, not just direct managers

I still believe in doing excellent work. But I no longer expect that to be enough on its own.

Blind spots aren’t the problem.
Not knowing you have them is.

Over the last few years, I’ve worked with dozens of founders and CEOs, helping them build core teams around their product. One pattern keeps showing up again and again - especially when they’re hiring their first or second product manager.

They want the perfect fit.

Someone who’s already worked in the niche.
Who understands the market.
Has the network.
Knows the tech.
Executes like a machine.
And somehow also builds the product strategy from scratch.

In short: a unicorn.

Subscribe now

But here’s what I’ve learned - both through my own experience and through helping others make the right calls.

That’s not what actually works.

Many of my clients start by chasing a candidate who checks every box. They want someone who’s done it all, and can do it all again. But the reality? These people are rare. And even when you find them, they might not be the right fit for you.

Meanwhile, open roles stay open.
Teams stay incomplete.
And competitors keep shipping.

So what if I told you there’s a better, more realistic, and more effective way to hire?

Here it is:

Hire people who know their blind spots.

When it comes to experienced managers - especially product managers - the most valuable trait isn’t deep expertise in everything.
It’s the ability to say:

“Here’s where I’m not strong. And here’s how I close that gap.”

That doesn’t mean they do it all alone.
It means they know how to bring in the right support.
The right person.
The right advice.
The right investment.
Whatever it takes.

A great PM doesn’t say, “I know everything.”
They say, “I know what I don’t know, and I know how to handle it.”

Expertise can be bought.
Self-awareness? Not so much.

And when hiring managers don’t think this way, here’s what happens:

They spend months looking for someone who doesn’t exist.
Or worse - hire someone who pretends to have it all figured out but lacks the humility to ask for help.

In my consulting practice, I’ve seen the opposite approach work every time.

When founders start hiring for self-awareness and adaptability instead of perfection -everything changes.

Time to hire drops.
Onboarding becomes smoother.
Results show up faster.

Not because the person is flawless.
But because they know how to:

— Buy advice
— Delegate
— Learn quickly
— Build the right team
— Focus on impact

No ego. No superhero act. Just momentum.

This works especially well for leadership roles.
Not as much for individual contributors, where tasks are immediate, measurable, and the cost of delay is low. ICs can often be replaced or hired later.

But for managers, it’s a different game.

They’re expected to build systems, adapt teams, and launch processes. Their ability to plug gaps—strategically—is a core part of their value.

So here’s my closing thought:

While you’re busy searching for a perfect match,
your team is waiting.
Your product is stalling.
And your competitors? They’re still moving.

Is chasing a unicorn really worth the delay?

I’ve been closely watching the evolution of AI since the 2022 hype wave.

Like many PMs, I’ve tried dozens of tools, prompts, and integrations. I’ve been impressed. I’ve also been disappointed. But above all, I’ve started to notice a pattern.

AI doesn’t crumble under logic. It crumbles under chaos.

Last week, I stumbled upon a discussion on Reddit’s /r/ProductManagement about PMs and the possibility to substitute them with AI. That post and the heated comments that followed hit home. Here’s why.

The real PM job is messy, and AI doesn’t do messy

Let’s be honest: writing a plan isn’t the job. It’s the easy part. The real challenge is what happens between the lines:

• Sales just promised a feature engineering hasn’t even heard of.

• Support is escalating customer issues that contradict the current roadmap.

• The CEO wants a "quick win" by next week, and Design is already overcommitted.

AI can summarize notes.

AI can rewrite emails.

But it doesn’t feel the tension in the room when marketing, engineering, and leadership pull in different directions. It doesn’t intuitively know when to push back, when to bend, or when to stay silent.

Good PMs are pattern matchers, diplomats, and sensemakers

Several people in that Reddit thread made an important point: the best PMs don’t just prioritize backlog items. They interpret weak signals, resolve conflicts, and influence outcomes without authority.

That’s not a to-do list. That’s a social puzzle. And so far, AI doesn’t play that game well.

Subscribe now

But let’s be clear — AI will replace bad PMs

The thread made me laugh when someone wrote, “The idea that even 20% of people with a PM title are doing real PM work is laughable.”

Harsh? Maybe. True? I think so.

PMs who just act as glorified ticket pushers? Replaceable.

PMs who simply echo sales requests and call it prioritization? Replaceable.

PMs who bring no user insight, no product intuition, and no strategic thinking? Replaceable.

And that’s a good thing.

The opportunity is not to compete with AI — it’s to collaborate

One commenter described how they combined Fireflies (call transcription) + Version Lens (AI agent) to get automatic digests of what sales teams were promising. That’s genius.

Another said it well: “PMs who use AI to amplify their judgment will eat lunch of those who don’t.”

That’s exactly how I feel. I use AI to:

• Analyze customer calls faster

• Draft early versions of user stories

• Spot recurring patterns in feedback

• Challenge my assumptions

But the final call? That’s still me.

Final thoughts

AI won’t replace product managers anytime soon. But it will expose the difference between those who manage tasks — and those who manage outcomes.

So if you’re a PM, the real question isn’t:

“Will AI take my job?”

It’s:

“Am I doing the kind of work AI can’t touch?”

Let’s hope the answer is yes.

When I started managing product teams, I kept hearing about velocity.

"Track your velocity."
"Improve your team's velocity."
"Velocity tells you if you're on track."

But no one told me what it actually meant — or how to use it.

Over the years, I learned that team velocity is less about speed, and more about visibility.
It’s about seeing how much work your team can realistically handle — and where their time is going.

Let me break down what I’ve learned, what worked (and didn’t), and share a simple template I now use.

Subscribe now

What is team velocity?

At its core, team velocity is a measure of how much work a team completes in a given period — usually a sprint or a month.

It’s not just a number for reports. It’s a way to answer key questions:

• How much can we commit to next sprint?

• Are we improving or slowing down?

• Is something draining our capacity?

Velocity helps you make realistic plans, not just ambitious ones.

Why bother tracking velocity?

Because assumptions lie.

You might think your team is spending 80% of their time on new features — but in reality, maintenance and unexpected tasks are eating half the sprint.

Without velocity, planning becomes guesswork.

With velocity, you get:

• Predictability in delivery

• Early warning signs when things drift

• A better way to say "no" (or "not yet") to stakeholders

How do you calculate velocity?

This is where it gets messy.

There are two popular ways:

1. Story points-based velocity

• Add up the story points completed in a sprint.

• Average them over time to see your team's typical capacity.

Pros:

• Works well with Agile teams using points already.

• Helps normalize across tasks of different sizes.

Cons:

• Story points are subjective.

• They require consistency, or they lose meaning.

2. Days-based velocity (my preference)

• Look at the actual number of working days per person.

• Factor in their focus (% time really spent on product work).

• Split it between new features and maintenance.

Story points vs. days: my take

I've used both. But here’s why I lean toward days-based velocity:

• It's grounded in reality.

• It highlights when people are dragged into meetings or firefighting.

• It’s easier to explain to non-technical stakeholders.

Story points are great — if your team uses them consistently.
But when I need a fast, practical view of what’s going on? I look at days.

My simple velocity tracking template

Here’s what I track for each team member:

1. Working days in the period

2. % Focus — are they really at 100%, or more like 70%?

3. % New features vs. Maintenance

4. Velocity — how many days are effectively contributing to the product?

5. Split — how much of that is on building new vs. maintaining old?

It gives me a quick view like this:

Examples: How I use velocity in real planning

Example 1: Deciding if we can take on a new initiative

I once had a stakeholder ask if we could start a new feature mid-quarter.
Thanks to our velocity tracking, I could show that 45% of the team's time was spent on maintenance, and we were already at 90% capacity.
We didn’t kill the idea — we delayed it. But with real data, not gut feeling.

Example 2: Spotting burnout risk early

In another case, one team’s velocity dipped sharply.
Instead of blaming performance, we checked the focus %.
Turns out, a key dev was stuck in cross-team meetings 50% of the time.
We fixed the process, not the person.

Example 3: Proving we need more resources

When pushing for extra hires, I used our velocity trends to show that growth was stalling because maintenance kept increasing.
It wasn’t a vague “we’re too busy.”
It was: “We spend 55% of our time just keeping things running.”

Final thoughts

Velocity isn’t just a metric. It’s a conversation starter.

Track it just enough to spot patterns, but don’t obsess over it. The goal isn’t to make the team faster — it’s to make better decisions with the capacity you do have.

And if you want a simple template to get started, just reach out — happy to share.

Template for measuring team velocity

You can copy it here.

Let me tell you a story about one of the best hiring processes I’ve ever gone through — and how I still didn’t get the job.

A few weeks ago, I applied for a senior product role at a company I genuinely admire. Their product lives right in the space I understand best: Outreach and sales automation.

I knew the niche.

I knew the pain points.

I knew the players in the market.

In short, I thought I had an edge.

I went through every stage:

✅ Calls with the team

✅ A full set of test tasks

✅ A product thinking deep dive

✅ A final call with the CEO

And honestly — I felt great about it. The feedback was positive. The design challenges felt solid. I knew my reasoning, and I explained it. I was all in.

But then the final email came:

“We really liked your strategic thinking and product depth… but we’re looking for someone with hands-on experience managing product teams and stronger analytical depth.”

Ouch.

So, what went wrong?

I’ve spent quite a bit of time thinking about this — and here’s what I realized.

1. Knowing the market ≠ securing the job

You can know the niche inside out — but the company might still be prioritizing something else.

In my case, they were looking for someone who had already built internal product processes, mentored junior PMs and established metric frameworks from scratch. That wasn’t clearly part of the role at first glance — but it was core to their decision.

It’s a humbling reminder: your strongest asset isn't always the most relevant for this specific role.

2. Your test task is not a deliverable — it’s a window into how you think

I worked really hard on my design task. I broke down flows, explained decisions, compared variations, and made strategic calls. That part actually worked — and it worked well.

If you’re going through a test task: don’t just “solve the thing.” Walk them through your thinking. The logic. The tradeoffs. The risks.

Good teams don’t just evaluate your output.

They want to know: Will I trust this person with ambiguity?

3. Even obvious things deserve to be said out loud

One of the things I underestimated was how much I needed to explicitly articulate ideas that seemed “basic” to me. For example: how we’d track the success of a feature. I mentioned MRR, DAU, MAU, churn — but I didn't go deeper.

That was the gap.

The team expected a more detailed approach — not just top-level metrics, but metrics tied directly to user behavior and feature success. They were looking for things like:

• Conversion rate per step

• Reply rate vs. Accept rate

• % of leads moving past specific actions

• Funnel drop-off between variants

• Time to action per lead

• Campaign health score

In retrospect, this is where I missed the mark. I generalized product analytics instead of tailoring them to the context.

What I did next

I created a simple but practical Product Metrics Cheatsheet — not for the hiring team, but for myself.

Something I can refer to every time I build a new feature or prepare for a metrics discussion.

Product Metrics Cheatsheet (not another list of MRR)

Retention & repeat usage (SaaS context)

Onboarding

Activation

Monetization

Feature adoption

Churn & retention risks

Product advice for PMs

1. Don’t stop at MRR and DAU.

   These metrics show business health, not product performance. You need behavior-level metrics to optimize actual user experience.

2. Track movement, not just events.

   Measure how users flow through your funnels — not just how many log in.

3. Tie metrics to decisions.

   Always ask: “What will I do differently if this number goes up or down?”

4. Own the context.

   Metrics are only useful if you know how the product works and what users are trying to do.

5. Be explicit in interviews.

   Even if something feels “obvious,” articulate the exact metric, why it matters, and how you’d move it.

Final thoughts

This process reminded me of something important:

Failing doesn’t mean you weren’t ready. It just means the fit wasn’t perfect — yet.

I don’t regret a minute of this experience. I built better habits, a sharper eye for UX patterns, and a stronger metric mindset.

Sometimes the job you don’t get helps you level up for the one that’s really meant for you.

One of the most persistent and damaging myths in product development is that an MVP (Minimum Viable Product) equals a low-quality, half-baked prototype that you should be embarrassed to release.

This misunderstanding has led countless startups to either overengineer their initial offerings or launch truly subpar products that damage their reputation from day one.

The truth is far more nuanced and empowering: a properly executed MVP balances minimalism with genuine quality, creating something small yet valuable that you can proudly present to the world.

The MVP Misconception: Debunking the Myths

The concept of Minimum Viable Product was coined by Frank Robinson in 2001 and later popularized by Steve Blank and Eric Ries in the context of the Lean Startup methodology.

Ries defined an MVP as a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.

Note the emphasis on viable – not barely functional or embarrassingly basic.

Yet misconceptions persist. Let's debunk the most common MVP myths:

Myth 1: An MVP is just a basic, stripped-down version of your product.
Reality: An MVP focuses on delivering essential features that provide clear value to users while enabling crucial learning for your team.

Myth 2: MVPs are only relevant for tech startups.
Reality: The MVP approach can be applied across various industries, whether you're developing a service, physical product, or digital tool.

Myth 3: The main goal of an MVP is making money quickly.
Reality: While revenue generation matters, the primary goal of an MVP is learning – testing assumptions, understanding customer behavior, and assessing market demand.

Myth 4: An MVP means lower quality standards.
Reality: Eric Ries never described MVPs as minimum products from a quality standpoint. He never advocated cutting corners, leaving defects in software, or launching poor-quality products.

As Eric Ries himself clarifies:

With an MVP we are not asking our teams to deliver low-quality work, we're adopting a strategy for driving excellence throughout the organization.

This perspective shifts our understanding fundamentally – MVPs aren't about lowering standards but about focusing effort on what truly matters.

Quality vs. Minimalism: Finding the Sweet Spot

The sad reality is that many MVPs fail because they aren't actually viable. As one expert bluntly puts it: "Creating a product that is 'okay' and tolerable doesn't mean anything. Even if the feedback is good, it can lead you into thinking that customers will be willing to use an 'okay' product which is extremely risky".

In today's competitive landscape, customers have high expectations and numerous alternatives. An MVP must deliver genuine value while remaining focused and streamlined. This requires finding the sweet spot between quality and minimalism.

The Minimum Viable Quality (MVQ) Concept

A useful framework emerging from this challenge is the concept of "Minimum Viable Quality" (MVQ), which Forbes describes as determining what the minimum of quality is viably necessary for that product or service to be acceptable to the marketplace.

This approach recognizes that quality isn't binary (perfect vs. terrible) but exists on a spectrum.

For your MVP, you need to identify:

1. The minimum quality threshold that makes your product viable for your target users

2. The essential features that deliver your core value proposition

3. Areas where you can maintain high standards without overbuilding

As Marina from Enlighten Services articulates:

The idea of MVP is to think 'lean' during product development and to challenge yourself on how to deliver high value with minimal effort and how to maximise the amount of learning during this process.

Why MVPs Fail: Learning from Common Pitfalls

Understanding why many MVPs fail provides valuable lessons for building better ones. According to comprehensive research, these are the most common reasons MVPs don't succeed:

1. Poor Market Understanding

Many MVPs fail because they target overcrowded market niches or don't have a clearly defined target audience. Before building anything, ensure you're solving a real problem for a specific customer segment.

2. Feature Imbalance

This manifests in two ways:

• Too many features: When "you're trying to squeeze in too many features at once, there is a high chance that the product will fail. When you have too many features in an early version, none of the features get enough time to be fully developed and tested".

• Too few features: Conversely, some MVPs fail because they don't offer enough functionality to be truly viable.

3. Poor Technical Implementation

Insufficient testing leads to a product riddled with bugs, glitches, or usability issues.

This disrupts the user experience and tarnishes the product's reputation, leading to lower user adoption. Quality in execution is non-negotiable, even for an MVP.

4. Failure to Iterate

The MVP is designed to be an iterative process. Failure to act on user feedback and continuously improve the product can lead to stagnation and, eventually, failure. Many products fail because teams launch and forget rather than launch and learn.

Frameworks for Building Quality MVPs

Several frameworks can help ensure your MVP strikes the right balance between minimalism and quality:

The UNITE MVP Scorecard

This scorecard evaluates potential MVP features based on:

• Prioritization: Scoring features by their importance to overall goals

• Alignment with objectives: Ensuring features contribute to product success

• Resource allocation: Identifying features offering the most value with least effort

• Risk mitigation: Focusing on elements crucial for validating key assumptions

• User-centric approach: Prioritizing what users find most valuable

The Six-Step MVP Success Measurement Process

1. Finalize the main goal your product should reach

2. List possible success metrics that are measurable and relevant

3. Collect both quantitative and qualitative data

4. Analyze findings and formulate hypotheses

5. Create and run tests to validate hypotheses

6. Reassess strategy and make corresponding changes

MVP Type-Specific KPI Framework

Different MVP approaches require different success metrics:

This framework helps tailor your quality assessment to your specific MVP approach7.

Success Stories: MVPs That Got It Right

Some of today's most successful companies started with well-executed MVPs that balanced minimalism with quality:

Dropbox (2008)

Rather than building a complex file synchronization system immediately, Dropbox founder Drew Houston created a simple 3-minute explanatory video demonstrating how the service would work.

This video MVP generated 75,000 signups for a beta version in just one day, validating demand before building the full product.

The key was that the video clearly communicated value and quality, even though the actual product wasn't fully built yet.

Airbnb (2007)

Founders Brian Chesky and Joe Gebbia faced a simple problem: they couldn't afford their San Francisco apartment rent.

Their MVP was remarkably minimal - they put three air mattresses in their living room and created a basic website offering short-term stays during a design conference.

This simple experiment proved people would pay for short-term lodging in someone's home, leading to what is now a global platform valued at over $83 billion.

Buffer (2010)

Joel Gascoigne wanted to test his idea for a social media scheduling tool, but instead of building the product first, he created a minimalist landing page that explained the concept and included pricing tiers.

When users tried to sign up, they were asked for their email address and told the product was coming soon. This simple MVP validated market interest before any development began.

Spotify (2008)

The initial Spotify MVP was a desktop-only application with a limited music catalog. The core value proposition was simple: listen to music seamlessly without downloading files.

By focusing on this one key feature and ensuring it worked extremely well, Spotify validated their concept before expanding to the comprehensive streaming platform we know today.

Each of these successful MVPs demonstrates a common principle: they didn't try to do everything, but what they did, they did well. They maintained quality in their core offering while keeping scope deliberately minimal.

How to Build an MVP You're Proud Of

Based on the frameworks, success stories, and expert advice from our sources, here are practical steps to build an MVP that balances quality with minimalism:

1. Start with Learning Goals, Not Feature Lists

When you think about building an MVP, you need to start by first thinking about what do you need to learn. Define the critical questions your MVP needs to answer:

• Do customers really have this problem?

• What are they doing today to solve it?

• What do they expect to gain from a solution?

2. Define Your Minimum Viable Quality

Determine the quality threshold necessary for your specific market and value proposition. As Kevin Krzeminski from McKinsey Digital notes,

MVP doesn't mean small. In fact, to me, it means a product that not only is achievable but also creates real value.

3. Focus on One Core Value Proposition

Identify your product's single most valuable capability and execute it exceptionally well. As exemplified by successful MVPs like Spotify, doing one thing extremely well is better than doing many things poorly.

4. Embrace Iterative Development

Continuously making bite-sized efforts at product development really accelerated delivery. Plan for rapid iteration from day one, with mechanisms to collect and act on user feedback.

5. Maintain Quality Where It Matters Most

Identify the aspects of your product that users care about most and maintain high quality standards in those areas. Compromising on core functionality or user experience will undermine your product's viability.

6. Use the Right MVP Type for Your Situation

Select the appropriate MVP approach based on your specific circumstances:

• Explainer video (like Dropbox) when you need to validate concept before building

• Landing page (like Buffer) to test market interest with minimal investment

• Concierge service to manually deliver what will eventually be automated

• Wizard of Oz approach when you want users to experience a seemingly complete product

Conclusion: Minimal Yet Mighty

The true art of creating an effective MVP lies in finding the perfect balance between minimalism and quality.

As product management expert Marty Cagan explains in his bestselling book "INSPIRED," successful product teams understand that:

An MVP is not about building half a product; it's about finding the smallest possible product that delivers customer value and allows you to start the learning process.

Remember that an MVP is not permission to create something subpar, but rather a strategic approach to learning efficiently while delivering genuine value.

By starting with clear learning goals, focusing on core value, maintaining quality where it matters most, and iteratively improving based on feedback, you can build an MVP that's not just viable but something you're genuinely proud to show the world.

Want to discuss an MVP?

Ever wondered why Spotify seems to know your music taste better than your closest friends? That eerily accurate Discover Weekly that somehow found that indie band you now can't stop listening to?

It's not magic - it's a sophisticated AI ecosystem working behind the scenes to understand your musical soul.

Spotify has quietly become one of the most advanced AI companies in the world, with over 1,100 patents globally that power everything from what plays next to how your playlists get created. Let's pull back the curtain and see what's really happening when you hit play.

What you will learn from the article:

• How Spotify’s AI algorithms work together to create your unique musical fingerprint.

• The technology behind your favorite Spotify experiences like Discover Weekly, AI DJ, and AI Playlist.

• Some of Spotify’s most intriguing AI patents that reveal the company’s forward-thinking approach.

• Insights into the data Spotify collects and how it uses it to enhance your listening experience.

and much more…

The brain behind your beats

Spotify doesn't just have an algorithm - it has dozens of them working together in a complex system that's constantly evolving.

Think of it as a musical brain that's been studying your every move.

"The recommendation engine is incredibly complex," explains an engineer who previously worked at Spotify. "It's not just looking at what you play, but how you play it—do you skip the song after 10 seconds or listen all the way through? Do you add it to a playlist? What time of day are you listening?"

This intricate system works across three main dimensions.

Your musical fingerprint

Remember that song you played on repeat fifteen times last Tuesday? Spotify definitely does. The platform meticulously tracks your listening habits to build what's essentially your unique musical DNA:

• Songs you like, add to playlists, or share to understand your explicit interactions

• Tracks you listen to completely versus skip to create implicit signals

• When and where you listen to certain genres to build your contextual patterns

These interactions create a constantly evolving profile that gets more accurate the more you use the service. It's why new users often find recommendations a bit hit-or-miss, while longtime listeners are stunned by how well Spotify "nails them."

Songs speaking to AI

How does Spotify know that an upbeat indie folk song might appeal to you more than a techno track? It listens to the music - literally.

Spotify's content-based filtering analyzes hundreds of audio characteristics in each song:

• Tempo and rhythm patterns

• Vocal presence and characteristics

• Instrumentation and production style

• Energy levels and dancability

• Acoustic qualities

But it goes deeper than just the sound waves. Using natural language processing, Spotify also analyzes lyrics, blog posts, reviews, and even social media discussions about artists and tracks. This helps the system understand the emotional and cultural context around music that pure audio analysis might miss.

The power of the crowd

You're not alone in your musical journey - and that's actually a good thing for recommendations. Collaborative filtering is Spotify's way of finding patterns across its 574 million users to predict what you might enjoy.

The principle is simple but powerful: if you like many of the same songs as another user, you might enjoy other songs they like that you haven't discovered yet. When scaled across hundreds of millions of listeners, these patterns become remarkably predictive.

What's fascinating is how Spotify balances familiarity with discovery.

As one patent describes it, the system actively works to introduce "calculated risks" in recommendations - songs that are slightly outside your comfort zone but still connected to your taste. Without this, you'd risk getting stuck in a musical echo chamber.

The features you know (and how they really work)

Those personalized playlists and features you love don't just appear out of thin air. Here's what's happening behind your favorite Spotify experiences:

Discover weekly: your Monday music gift

Every Monday, millions of Spotify users eagerly check their Discover Weekly playlists. But how does it work?

The process starts with analyzing your recent listening history and finding your "taste profile." Then it identifies users with similar taste profiles and examines what they're enjoying that isn't in your rotation yet. The system then curates 30 songs that it believes you'll enjoy but likely haven't heard.

What's crazy? Each of these playlists is completely unique—no two users receive the same Discover Weekly, even if their tastes seem identical. That's because the system is considering thousands of micro-factors that differentiate even similar listeners.

AI DJ: your personal music guide

When Spotify launched AI DJ in 2023, it represented one of the company's most ambitious AI implementations yet. The feature combines:

• A sophisticated recommendation system that builds personalized lineups

• A realistic AI voice model (initially based on Xavier "X" Jernigan)

• Commentary that contextualizes why songs were selected for you

The results have been impressive—users spend 25% of their listening time with DJ on days they use it, and more than half of first-time listeners return to it the next day.

What makes AI DJ particularly interesting from a technical perspective is that it doesn't just select songs—it creates a narrative around them. The system uses natural language generation to craft commentary that feels spontaneous and personalized, making it feel more like a friend sharing music than an algorithm.

AI Playlist: creating with prompts

Remember the mixtapes you used to make for friends? Spotify's AI Playlist feature (launched in beta in April 2024) is the AI-powered evolution of that concept.

This feature allows you to create playlists by simply typing text prompts like "music for a rainy Sunday morning" or "songs that make me feel like the main character." The system interprets these prompts using natural language processing and generates a tailored playlist based on both your request and your listening history.

What's happening technically is fascinating: the system is combining generative AI with Spotify's existing personalization technology to interpret abstract concepts and translate them into musical selections. It can process references to moods, places, activities, movie characters, and even emojis.

Microservices that make the music flow

Rather than one massive program, Spotify's AI runs on a microservices architecture -essentially hundreds of specialized mini-programs working together.

This approach allows different teams to develop and refine specific AI components independently while enabling the entire system to scale efficiently.some of Spotify’s most intriguing AI patents that reveal the company’s forward-thinking approach.

Kevin Goldsmith, former CTO at Spotify, confirmed this approach allows the company to constantly experiment with new AI features without disrupting the core service. When you open the app, dozens of these microservices spring into action to create your personalized experience.

The patent powerhouse

Spotify's 1,124 global patents (649 of them granted) reveal just how seriously the company takes AI innovation. Some of the most interesting patents include:

Speech analysis and emotion detection. A 2021 patent that enables Spotify to analyze voice patterns to detect emotional states and demographic attributes. The patent describes using "prosaic information" within a "hidden Markov model architecture" to categorize emotions like happy, angry, afraid, sad, or neutral.

Lyrics analysis system. This 2020 patent deploys AI to classify songs based on lyrical content and technical characteristics, generating tags and explicitness indicators while identifying key themes.

Breaking artist prediction system. Granted in March 2022, this technology creates a system for predicting emerging artists by monitoring patterns among users who tend to discover artists before they become mainstream.

These patents aren't just theoretical—they're actively implemented in features you use every day, from content recommendations to the Spotify Wrapped experience.

How much does Spotify really know about you?

In reality, Spotify collects an enormous amount of data to fuel its AI:

• Every song you play, skip, or add to a playlist

• When and where you listen (time of day, device type, location)

• How long you listen to particular tracks

• Your volume adjustments during specific songs

• Your search queries and browsing patterns

One of Spotify's more controversial patents even describes monitoring users' speech patterns and background noise to detect emotional states and social settings.

Does this mean Spotify is always listening? The company says no—these features would require explicit opt-in. But the patent shows how far the company is thinking about personalization.

The unexpected ways Spotify uses AI

Beyond recommendations, Spotify employs AI in several surprising applications:

Podcast translation

Using AI, Spotify translates podcasts into different languages without requiring creators to produce multiple versions. This expands reach for creators while making content more accessible globally.

Audio quality optimization

Spotify uses AI to dynamically adjust streaming quality based on your connection strength and listening environment. The system can predict potential buffering issues before they occur and adjust accordingly.

Fighting AI-generated music spam

In a twist of irony, Spotify uses AI to detect and remove AI-generated music that floods the platform. In May 2023, the company reportedly removed tens of thousands of AI-generated songs created by the music generator Boomy due to suspected artificial streaming.

What's Next for Spotify's AI?

Spotify continues to push the boundaries of what's possible with music AI. Future developments might include:

• More sophisticated voice interaction capabilities

• Enhanced spatial audio personalization

• Greater integration between music and podcast recommendations

• More advanced AI-created content like personalized DJ commentary

• Tools that help human artists collaborate with AI

The company's patent portfolio hints at even more ambitious applications, including systems that could generate completely personalized music based on your mood and preferences.

The human touch in the algorithm

For all its technical sophistication, Spotify's AI success ultimately comes down to how well it understands human emotion and connection through music.

"Music is fundamentally emotional," says one Spotify product manager. "Our challenge isn't just building accurate recommendations—it's understanding the mood you're in, the mood you want to be in, and finding the perfect songs to bridge that gap."

That's why Spotify continues to employ human playlist curators alongside its AI systems. These experts help train the algorithms and create editorial content that informs machine learning models.

In the end, Spotify's greatest achievement isn't just building powerful AI—it's making that AI feel invisible. When the system works perfectly, you don't think about the complex technology making predictions about your taste; you just enjoy the perfect song at the perfect moment.

And isn't that what music is all about?

Her name is Olga, and she is the CEO and founder of Shopperations.com — a successful SaaS product focused on collaboration in the field of shopper marketing.

Shopper marketing is a strategy that uses insights into shopper behavior to influence purchasing decisions at critical points in the customer journey1. It aims to provide people with what they are looking for at the right moment, blending data, creativity, and timing to increase sales and build brand loyalty.

Back in 2015 I helped Olga build the first version of Shopperations. We spent countless hours over designs, tasks, implementing and testing.

Nearly a decade later, it’s fascinating to hear her success story — one that began as a product MVP and gradually grew into a mid-sized SaaS company.

Let´s begin.

How did the idea for Shopperations come about?

I always wanted to be an entrepreneur, that is why you come to America, right? I dabbled in various ideas but none of them felt like I could build a sustainable, profitable business around. At the same time, I kept working in my day job in corporate America as a marketing director. By 2014, I had close to 15 years of experience working in various marketing roles in the Consumer Packaged Goods (CPG) industry. I remember feeling a lot of frustration because of how manual and inefficient my work was due to lack of tools and process automation.

I begged my management to buy or build us a software for managing budgets, promotional plans, track marketing invoices and simplify management reporting. They heard my pleas and commissioned a contractor to build it. I was supposed to be the beta tester of the software. As soon as I saw its first version, I realized that the software was nowhere near where we needed it to be. Looking back at that moment, I realize that they neither did the proper user research nor practiced agile software development methodology.

Ironically, that same day, my company was doing the reorganization and offering severance packages to employees who voluntarily resigned. I saw that as a sign from above that I had to try to build a software like that myself.

The vision for the software was already in my head, now I just needed to figure out how to build it.

What problem were you trying to solve in the shopper marketing industry when you founded Shopperations?

In the era before Shopperations, more than half of marketers’ time was spent in internal meetings, sifting through multiple Excel documents, manually aggregating, summarizing and formatting data. The data was riddled with errors, obsolete and often incomplete. Answering simple questions like:

1. What is my current budget?

2. How much of the budget is committed?

3. How much did we spend on brand A last year vs. this year?

4. At which retail chains did we promote Brand B last quarter?

5. Who are the biggest media vendors we work with?

6. What marketing tactics are taking up more spend and which ones are declining year-over-year?

7. Etc….

…was really difficult, and took hours if not days, to manually collect information, taking time away from productive activities.

Because there was no one place to see all marketing activities, marketing spend was often seen as a “black hole”, making it difficult for their colleagues and bosses to see and appreciate all the work that the team was doing.

Inability to see the total marketing investment for the brand across multiple retail accounts often resulted in excessive discounts that the headquarter-based marketers unknowingly “layered” on top of retailer-specific promotions, eroding brand profitability.

Can you walk me through the process of developing the MVP for Shopperations? What were the biggest challenges?

My personal experience working in the industry gave me a pretty good sense of what the core features of the software should be, however, I still sought validation from future clients.

The first prototype I built was a clickable HTML front end with no back end. We created it in about a week with a local developer. It was before I knew about UX design software like Figma (did Figma even exist in 2014?), so we probably spent more time on it than necessary. Nevertheless, it was a great way to demo for potential clients and get their initial reactions. Most of my early meetings were very positive, and I could sense that clients were excited about the possibility of having a software that was built just for them by a person who lived through their pain.

My biggest challenge at that point was not necessarily technical, rather mindset related. I wasn’t feeling confident enough to ask for a purchase order. I spent quite a bit of time just showing the prototype and taking notes, instead of asking clients “What would you be willing to pay for it, and can you help fund the development?”. At some point, I found a mentor who told me to exploit FOMO and give clients a chance to sign up for an “Early Adopter Program” that had low cost of entry and gave them a seat at the table to co-develop features and the UX. I had my first sale shortly thereafter.

I also was lucky because my former boss was gracious enough to give me a non-binding letter of commitment stating that the company would be willing to pay for the software if/when I have my MVP ready. That was a very powerful sign that allowed me to get a state grant to build the MVP. The grant essentially paid for most of the MVP and allowed me to test it “in vivo” with my first clients.

Another challenge was to assemble a competent tech team that could deliver the product. I spent some time “dating” potential technical co-founders locally but wasn’t successful in finding a perfect fit. That’s why, once I got a state grant approved, I hired a Ukrainian software development agency to make it happen, and it was a very positive experience.

How did you approach market validation and building your first user base?

Once I had an MVP (which, by the way, was very robust and complex) and several early clients, I began my marketing and sales efforts. I started learning about inbound marketing and hired a local Hubspot partner agency who set up the CPM & Marketing automation system for me and taught me now to blog, write white papers, build landing pages, distribute my content on social media and via email. I soon discovered that my niche didn’t have much content clutter, so I was able to gain awareness and brand recognition relatively quickly. I love blogging and discussing industry issues, reminiscing about my past experience working in the corporate marketing role and sharing the story of Shopperations. One of my first blog posts converted a major client for me, I was able to schedule a demo and close the deal in less than three months (very fast by my industry standard).

My early clients were awesome, patient and very supportive. They agreed to co-present case studies at the industry conferences and share their experience automating their marketing planning process and working with Shopperations.

There is no one single way to find early clients. You have to reach out to your existing contacts, do cold emails to complete strangers, network on LinkedIn, publish engaging, authentic content and build a reputation in your niche. After 10 years, I still feel the same, only now we have a large user base who often switch employers and recommend us to their new companies, i.e. referrals are a bigger part of the sales process.

Can you share any decisions that contributed to Shopperations’ success?

I believe that the fact that I decided to quit the corporate world “cold turkey” and focus on Shopperations 100% for some time was the right decision. It allowed me to go faster and sent the right signal to potential investors and clients who wanted to see my full commitment to the idea. Fortunately, I was able to afford this lifestyle due to generous severance from my old employer and my spouse’s income.

Another decision I had to make that ultimately worked for me was to hire a dev partner, rather than continue looking for a technical co-founder. The team I ended up working with is highly skilled, well-staffed and professionally run. I learned from them how to do agile software development and what great project management looks like. We are still working with the same company 10 years later.

Focusing efforts on in-bound marketing rather than only on outbound sales was also a good call. It felt authentic, natural and less forced to find like-minded professionals who sincerely reacted to my content and engaged in conversations with me. The content I created 8 years ago is still relevant and driving traffic to my site.

Finally, hiring and retaining a super-talented customer success lead was absolutely the right thing to do. She is very strategic, comes from the same industry and can speak to clients with authority about their business challenges, not just about technical issues related to software. She keeps current users happy while I can focus my attention on winning new accounts.

What were some of the most difficult decisions or setbacks you encountered, and how did you overcome them?

Losing a major account was a big blow in 2020. We discovered that their IT department contracted a competitor and piloted their software in another country, and that my current users didn’t have a major stake in that decision. While our US deployment was successful and we delivered significant cost savings and efficiencies to the client’s local marketing team, we didn’t have a strong relationship with their IT organization. Lesson learned - network inside an enterprise and understand the “hidden” decision makers or influencers.

I also lost one major RFP because I tried to negotiate harder. I was under the impression that the RFP was just a formality because the future users loved the demo. However, in the process, Procurement stepped in and brought in alternative suppliers of similar software. I got the client’s counter offer, which I considered to be low-ball, attempted to counter it back, and lost. Lesson learned - low ball offers may be ok for strategic accounts, just to get your foot in the door.

What advice would you give to other entrepreneurs looking to launch an MVP or scale their product?

If you are building a B2B product, look for early adopter clients who are willing and able to take a risk and fund your MVP. Do not do free trials because when there is no skin in the game, they will not give you enough attention and will not give you honest feedback.

How do you find those clients? Someone had a great suggestion: while networking, bring up a very futuristic topic and see if their eyes light up. If they geek about the possibilities that technology will bring and love to try new things, they will likely be able to appreciate what you are building.

Use Figma or similar UX design prototyping software to share your vision of your product with clients. Take feedback and come back to them ASAP to demonstrate how you address their input, then don’t wait too long to do the “ask” - there will be many people who will love chatting with you but who don’t have any power to give you a sale. The worst that can happen is they tell you no and stop wasting your time or make an intro to someone in their company who holds the purse strings.

When you have a decent idea of what your MVP is and have excited clients who are willing to give you a purchase order, you can raise money faster. But raising capital is not always necessary. If you can afford to build an MVP using your personal savings and co-develop with clients who prepay your software, you can maintain 100% of your company and be less distracted raising capital and managing investors.

Don’t wait for the MVP to be finished to begin marketing it. In hindsight, I could have started my email and inbound marketing efforts way earlier. It takes time to build a following and to warm the leads to a point where they are ready for a sale. Your early inbound efforts can be focused on finding early adopter clients, that is what I should have done.

Bonus question: Do you follow the latest AI trend in Shopperations, and build any AI features?

I am watching this space carefully and dabbling in AI myself, automating many of my day-to-day tasks. There are several ways AI could be applied in Shopperations today, but our clients are not demanding it… yet. I am also waiting for the technology to mature and become more affordable, to learn from other B2B software products’ experience and reapply best practices. When it comes to AI, we will be a fast follower, not an early adopter.

Get MVP Help Now

Statistics say that around 90% of startups fail, with 70% failing within the first 5 years. The major reason (over 35%) is that there is no market need for the product.

Countless startups invest years into building products that actually have little market demand or no market demand at all.

Founders often assume that having a great idea and executing it or adding more features will guarantee success.

Let me assure you: this rarely happens. Here comes a common pattern for failed startups:

Get excited about an idea → spend months building it → launch to complete silence → become discouraged → repeat the cycle.

There is a recipe to overcome this cycle. It is both easy and difficult at the same time: successful founders always prioritize market validation over prolonged development cycles.

Market validation: What works and what doesn’t

Based on my experience, I have collected a few cases that work, and some that won´t help you develop your product.

What works:

Finding people already searching for a solution

Instead of sending cold messages (which can work in some cases), successful founders actively look for potential customers who are frustrated with existing solutions or are searching for possible solutions.

Searching for discussions like “Does anyone know a tool that…” or “I’m frustrated with [competitor]” provides opportunities to find real users genuinely seeking alternatives.

Trying to help, not to sell

You should offer real value to your customers if you want to reach out to them successfully.

To increase trust, you should provide a solution to their pain point or at least answer their questions before even mentioning your product.

What doesn’t work:

• Classical cold outreach - people will ignore your emails about a “new revolutionary platform.”

• Waiting for SEO to do its job. SEO is a powerful tool, but it takes months or years to provide effective results.

• Building an all-in-one solution. Early versions of the product or even product MVPs that are overloaded with unnecessary features often confuse users rather than attract them.

Note: while traditional cold outreach (mass emails and generic pitches) rarely works, warm outreach can be highly effective when done right.

Personalized emails or LinkedIn messages that reference a specific challenge the recipient is facing, or a mutual connection, can open doors. Instead of pushing a product, focus on starting a conversation and providing value upfront.

The "ready-to-buy" framework

Here are three simple scenarios when users will want to buy your product:

Actively searching for a solution

This is the best-case scenario that may happen in real life. People have countless issues that they want to deal with. All you need is to listen to them, understand if the problem is real, and offer your solution.

Where to find them:

• Search for discussions on Reddit, Twitter/X, Quora, Indie Hackers, Slack, and LinkedIn groups where users ask, “Does anyone know a tool that…?”

• Monitor Q&A sites like Stack Overflow or Product Hunt for questions about your niche.

• Use advanced Google search operators (e.g., “best [your niche] tool” site:reddit.com).

How to engage them:

• Offer value first—provide insights or recommendations before mentioning your product.

• Ask follow-up questions to better understand their needs.

• Share free resources, templates, or quick solutions that build trust before suggesting your product.

Frustrated with existing options

This is another excellent scenario: offering a similar product, but cheaper or better.

Where to find frustration signals:

• Read negative reviews on platforms like G2, Capterra, Trustpilot, and App Store/Google Play. Look for repeated complaints (e.g., slow performance, bad UI, poor support).

• Follow social media discussions where people complain about competitors. Search Twitter/X for phrases like “I hate [competitor name]” or “[competitor] is too expensive”.

• Analyze support forums or comment sections where users request missing features.

How to position your product:

• Don’t just say you’re better—show exactly how you solve the frustrations users have with competitors.

• Run targeted ads that highlight weaknesses in competitors (e.g., “Struggling with [competitor’s common issue]? Try this instead.”).

• Reach out to frustrated users directly with a free trial or demo addressing their pain points.

Asking for product recommendations

These users are already in a buying mindset. Converting for such people is five to ten times higher than for cold leads.

Where to find them:

• Monitor Reddit threads, Facebook groups, LinkedIn posts, and Slack communities where people ask for recommendations.

• Engage in product comparison discussions (e.g., “What’s better: X or Y?”) and position your product effectively.

• Keep an eye on newsletter comments, Twitter threads, and niche forums where professionals ask for tools in your domain.

How to increase conversions:

• Create comparison content (e.g., “How [your product] compares to [competitor]”) and share it when relevant.

• Encourage happy users to recommend your product by building a referral program (e.g., discounts, exclusive features).

• Offer a clear, compelling reason to choose your product—whether it's better pricing, stronger features, or a unique approach.

By focusing on users who are already primed to buy, you significantly increase your chances of success while reducing wasted efforts on cold outreach.

Real-world examples of successful validation

Zappos – testing the market before scaling

Zappos is an online retailer known primarily for selling shoes, clothing, and accessories. Instead of investing heavily in inventory, Zappos’ founder Nick Swinmurn tested the market demand by photographing shoes in local stores and listing them online.

When customers made a purchase, he simply bought the shoes from the store and shipped them. This allowed Zappos to validate the online shoe market before committing significant resources.

Superhuman – Targeting early adopters

Superhuman, a premium email client, didn’t aim to attract all users at once. Instead, the company focused on a niche audience - power users who were frustrated with existing email solutions.

The team conducted multiple user interviews to identify real pain points with Gmail and Outlook and later designed a product addressing those specific issues.

Basecamp – Focusing on essential features

Basecamp is a project management and team collaboration software for more efficient team collaboration.

It succeeded by solving a specific pain point - project management for small teams. Instead of adding every possible feature, they concentrated on the most critical ones, ensuring a simple and effective user experience.

The market was already crowded, but they stood out by eliminating unnecessary complexity from the product.

Key lessons for startup founders

I have gathered these valuable insights while working with successful and failed startups during the last 10 years:

• Start with a product MVP to do one thing well, focusing on core functionality only.

• Build your product around a specific pain point. You should solve a clearly defined problem.

• Choose technologies within your expertise that speed up development instead of searching for fancy tools.

• Engage with potential users directly instead of waiting for organic traffic.

• Charge from day one. Monetization should be part of the plan from the start, not an afterthought. If users aren’t willing to pay, your product might not be solving a real problem.

Following these principles, as a startup founder, you can avoid common pitfalls and increase your chances of building products that people actually want.

Want an expert advice?

New challenges appear at a constant pace, requiring PMs to make quick decisions while staying focused on long-term goals. The ability to navigate these situations effectively is what distinguishes a good PM from a great one.

An axiom: every product manager faces the challenge of balancing multiple demands.

How do you manage these demands while keeping the team focused and motivated? How do you ensure that your decisions serve the broader vision of the product, rather than just reacting to the loudest voices?

Here’s a practical approach based on my experience as a product manager.

1. Accept That You Can’t Make Everyone Happy

One of the first lessons that I´ve learnt is that you will inevitably disappoint some stakeholders. Your job isn’t to make everyone happy - you are not therapist. it’s to move the the product to success. If you understand this, it´ll be easier to say no when necessary and to focus on what truly matters.

Subscribe now

Make it as a strategy, when declining a request - acknowledge its importance and work through possible compromises. Here is a simple framework:

• Start with understanding the problem and gather context.

• Explain the current priorities and constraints.

• Explore possible trade-offs or alternative solutions.

• Finally, make a decision and communicate it transparently.

Even if a stakeholder isn’t happy with the outcome, they will appreciate the clarity and fairness of the process.

2. Prioritize Based on Product Objectives, Not Just Stakeholder Demands

Remember that not all priorities are created equal, but there might be competing ones. To manage them effectively, align every decision with well-defined product and company objectives. If a request doesn’t move the product closer to its goals, you shouldn’t take it as a priority.

Here are some points to make a more structured prioritization:

• Ensure that you have defined objectives to the leadership clearly.

• Use frameworks like RICE (Reach, Impact, Confidence, Effort) to evaluate initiatives.

• Be transparent about why certain priorities come first.

With this approach you can justify tough decisions and maintain focus on the bigger picture easier.

3. Create a Clear System to Prioritize Objectives

There is a common mistake that makes you treat multiple priorities as equally urgent. Instead, you should assign clear rankings. For example:

1.0 - Mission critical (essential for product success).

1.1 - High priority (strong impact, but not urgent).

1.2 - Medium priority (valuable but not time-sensitive).

2.0 - Low priority (nice to have, but not urgent or critical).

Using this approach, you create a decision hierarchy and ensure that work is focused on really important objectives.

4. Be Proactive in Managing Stakeholder Expectations

One of the golden rules that I´ve learned is that stakeholder management is just as important as prioritization. Stakeholders are happy when you keep them informed about what’s being worked on and why. Try out some strategies.

Hold monthly or quarterly stakeholder meetings to align on priorities. Share a living document showing upcoming work and priorities. Use user feedback, surveys, and metrics to validate prioritization choices.

5. Don’t Accept Feature Requests at Face Value

Stakeholders often come with specific feature requests, but it’s crucial for you to dig deeper into the underlying problem. Instead of immediately adding a request to the backlog, you should ask:

• What problem are we trying to solve? (possibly the main and the most important question).

• What alternatives have been considered?

• How does this align with product goals?

• What is the impact if we don’t do it?

When you shift the conversation from solutions to problems, you can better assess what truly deserves prioritization.

Subscribe now

6. Communicate Trade-Offs Clearly

Every decision involves trade-offs. When priorities shift, make sure that all stakeholders understand what will be deprioritized as a result. A structured way to communicate trade-offs is the following:

• Clearly state what’s being added, delayed, or removed.

• Provide rationale based on product goals and impact.

• Outline potential risks and benefits.

• Align on any necessary adjustments or alternative solutions.

7. Use Data to Support Your Decisions

When stakeholders push you for competing priorities, make data your best ally. Instead of making decisions based on opinions, use:

• User feedback and surveys that rank customer pain points and feature requests.

• Product analytics to track engagement, adoption, and conversion metrics.

• Market research to compare industry trends and competitor offerings.

This makes it easier to justify decisions and minimize pushback from stakeholders.

Final Thoughts

Of course, it is not easy to handle competing priorities as a product manager. However, a structured approach makes it more manageable. Align priorities with product goals, maintaining transparency, and communicating trade-offs effectively, so you can keep both stakeholders and your team focused on what truly drives product success.

Even if not everyone will be happy with your decisions, the clear process based on data will earn their trust and support over time.

Want expert advice on prioritization?

Imagine you’re building a website. You don’t start with a fully designed platform offering the complete variety of services. Instead, you create a simple landing page that can collect email addresses and provide a brief description of your product.

That landing page is your website MVP, or Minimum Viable Product. It is the simplest version of your product that solves a real problem for your audience - it generates early interest and gathers user feedback before you invest significant amount of money into a full-scale platform.

A minimum viable product (MVP) is not about saving money and cutting expenses. It is rather about learning efficiently and verifying early. For example, when Dropbox launched, their MVP wasn’t a fully functional platform. Instead, they created a simple video demonstrating how the product would work. This approach validated their idea before investing significant money in product development.

Why Does an MVP Matter?

Starting with an MVP can save you time, money and efforts. It lets you test your idea in the real world without committing to a full-scale build. Here’s why it’s so powerful:

• Reduces risk, so that instead of gambling on a fully developed product, you gather data early.

• Speeds up feedback, so you’ll know within weeks (or even days) if your idea resonates with users.

• Guides future development and allows early users to shape your roadmap, ensuring you build what people actually want.

For instance, Instagram began as a simple photo-sharing app. They didn’t start with features like Stories or Reels. By focusing on one Photo filters feature they gained traction and grew from there.

Subscribe now

How to Prepare Your MVP for Launch

Launching an MVP doesn’t mean rushing to get it out the door. Proper preparation makes all the difference. Start by identifying your audience. Understand exactly who you’re building for because clarity about your target users directly impacts your chances of success.

Then, set clear, measurable goals. Decide what you want to learn from this launch - whether it’s validating demand, assessing usability, or something else entirely.

Finally, test your MVP internally with a small group before the official release. This step helps catch significant issues early and builds confidence in your product.

Take Slack as an example. Before they went public, they tested their product within their own team. This allowed them to refine its functionality while staying aligned with its purpose, ultimately setting the stage for a successful launch.

The Role of Feedback in Refining Your MVP

Your MVP is just the starting point, not the final destination. Feedback plays a crucial role in shaping it into a product that resonates with your audience. To gather meaningful insights, ask open-ended questions. Instead of asking, “Do you like it?” try, “What’s missing?” or “How could this be improved?” Focus on identifying recurring themes in the responses, as these patterns often highlight the most pressing areas for improvement. Then, use the insights to make small, focused changes quickly. Perfection isn’t the goal at this stage—iterative progress is.

Consider Airbnb’s journey. Their initial website was far from polished and barely worked. But by engaging directly with early users, they uncovered which features mattered most. This feedback drove the evolution of their platform into the successful business it is today.

Common Mistakes to Avoid with MVPs

While building and launching an MVP can be exciting, it’s easy to make mistakes along the way. Overloading your MVP with too many features is a common error. Adding unnecessary elements often dilutes the core value of your product and confuses users. Another frequent misstep is skipping research. Building on assumptions without validating your idea can lead to wasted resources and missed opportunities. Finally, ignoring user feedback is a critical mistake. If your users aren’t engaged, resist the urge to blame them. Instead, dive deeper into their experiences, find out why, and make changes to adapt.

By avoiding these pitfalls and taking a thoughtful, feedback-driven approach, your MVP can grow into a product that truly meets user needs.

Final Thoughts

An MVP is your product’s first step into the real world. It’s not about impressing everyone; it’s about learning and growing. Start small, focus on solving one clear problem, and let feedback guide you. Remember, launching an MVP is less about perfection and more about progress.

So, what’s your next move? If you’ve got an idea, take that first step. Build your MVP, share it, and see what happens. The journey from idea to product always starts with a single launch.

Want expert advice on building your MVP?

Understanding and clearly defining the North Star Metric is important for product managers, and today I want to explain why.

Before diving into the specifics, let’s talk about metrics in general. Metrics are indicators that help track the effectiveness of different aspects of a product, such as its functionality, business results, or user engagement.

Metrics are typically focused on specific goals or issues that need to be measured. For instance, in SaaS products, Monthly Recurring Revenue (MRR) is used to determine the stable income a company receives monthly from subscriptions.

Another critical example is Daily Active Users (DAU). This metric provides insight into user activity within a product per day and is essential for gauging user engagement. DAU is often paired with Monthly Active Users (MAU) to provide a more comprehensive view.

If you’d like to delve deeper into product metrics, I’ve written a separate article that explores them in detail.

Now, back to the North Star Metric (NSM). The term ‘North Star’ likely originates from the star that sailors used in ancient times to navigate their ships across the sea.

In the business world, the term represents the most crucial metric for a company. The NSM serves as a guiding star, pointing the direction for a company’s development and defining its strategic focus.

What Makes the NSM Special

The NSM is a single key metric that reflects the long-term value a company delivers to its customers. It aligns all teams across the company towards a shared goal, ensuring everyone’s efforts contribute to the same overarching objective.

To illustrate this, let’s look at the NSM of a well-known company, Airbnb. For Airbnb, the NSM is the number of nights booked. Why is this metric significant?

For guests, the core value Airbnb provides is the ability to find suitable accommodations for their stays. For hosts, it’s the chance to rent out their properties and earn income. The number of nights booked is a direct measure of how well Airbnb fulfills these needs.

Moreover, this metric impacts Airbnb’s revenue model, as the company earns a commission for each successful booking. Thus, the NSM of number of nights booked helps Airbnb stay focused on its core mission: connecting travelers with unique accommodations.

Examples of North Star Metrics from Various Companies

Here are several examples of NSMs from prominent companies. While no metric is perfect, these examples clearly represent the long-term value these companies aim to provide to their users:

• Spotify: Time spent listening

• YouTube: Minutes watched

• Airbnb: Number of nights booked

• Amazon: Transactions per user

• LinkedIn: Monthly active users (MAUs)

• Facebook: Daily active users (DAUs)

• Uber: Rides per week

• Netflix: Total hours viewed

How to Identify the North Star Metric for Your Product

Determining your North Star Metric requires identifying what’s truly essential to your business. Every business is a complex entity, and success depends on numerous factors. However, what are the fundamental elements that, like load-bearing structures in architecture, must be intact for the company to thrive?

For many businesses, these fundamental elements include ensuring customer satisfaction, generating profit, and monitoring progress toward these goals.

A metric that only tracks revenue without considering customer satisfaction will not be effective in the long term. Similarly, a company that prioritizes customer happiness but fails to be profitable cannot sustain itself. Finally, a metric that doesn’t allow for insights or behavior adjustments is ineffective.

Subscribe now

An ideal NSM should encompass all these factors, tailored to the specific nature of your business. Here’s how you can start identifying your North Star Metric:

• What is crucial for the company’s operations? List and prioritize these aspects.

• Which key performance indicators (KPIs) and metrics align with the identified items?

• Which of these metrics embodies all the elements mentioned above?

Once you’ve answered these questions, arrange your metrics in a hierarchy, placing the NSM at the top.

Instead of a Conclusion

Just like a plant, your North Star Metric needs the right environment to flourish. Companies that choose an NSM require a culture and infrastructure that support it.

Cross-departmental cooperation and a culture that prioritizes the company’s collective goals over individual team interests are essential.

Resistance can arise if employees face significant behavioral shifts or if their compensation structures, such as those in sales teams, create a conflict of interest.

Using North Star Metrics can effectively align teams toward shared objectives, but they need to be flexible.

They should not be adhered to rigidly but should be supported by a culture that adapts to changes and uses analytics to assess their relevance and effectiveness.

Above all, remember that growth and success are the ultimate goals.

This means that your North Star Metric or any focus metric may need to be refined or adjusted as your company evolves or shifts its mission.

Being open to reassessment is essential; no one wants to waste resources pursuing an unproductive path.

At the same time you begin collecting metrics for the group A and group B. These metrics vary depending on the functionality you are testing, for example how many users have clicked on the modified UI element compared to the existing one.

In some cases you might have more than two variants in order to get more diverse results, and conduct A/B testing faster.

You must also try to understand whether the changes in the observed metric between the groups A and B are caused by testing itself or not. To do this, you should conduct at least several randomized A/B tests.

Subscribe now

When and Why You Should Run A/B Testing

You should conduct A/B testing when you want to understand if making changes to a tested group (for example, offering an updated registration flow) will lead to changes in the outcome.

It is often conducted to optimize specific metrics, such as conversion rate, click-through rate, or user satisfaction.

A/B testing is your proof that the changes really occur when comparing the control group with the test groups.

Sometimes, even the smallest changes in the measured metrics may have a significant impact. For example, improving website loading speed by a few milliseconds may significantly increase revenue.

Also, A/B testing may lead to unexpected results beyond the metrics measured, providing you with valuable information.

For example, if you were conducting a test of a new Buy button, the main metric — number of clicks — might remain almost the same. However, you may find that users start complaining about the new button, as it worsens their experience.

Of course, it’s not always that the “B” Buy button is worse than the “A” Buy button; it might even be better overall. People may simply be accustomed to the old one and reluctant to change their behavior. This is one of the obvious issues with A/B testing.

Necessary Components of A/B Testing

First of all, you should have your test subjects to conduct A/B testing, i.e. users and be able to split them into two or more test groups. To make testing accurate there should be little or no interference between the users.

Second, the number of users should be sufficient for testing. Without enough users, the results may lack statistical significance, making it difficult to draw reliable conclusions. This means you need a sample size large enough to detect meaningful differences between the test groups.

You should remember that it is harder to detect smaller changes than the larger ones, but still they might be considerable.

And finally, you must define metrics that will be used to measure the results of testing. For example, measuring user engagement could be a good metric.

Subscribe now

What Does A/B Testing usually show

This is a great observation, and I want to share more about it. We create features thinking that they will be useful. However, in reality, the majority of features do not improve the metrics they were intended to.

Successful Case Studies of A/B Testing

I have taken these examples from Conversion.com. You can clearly see that even slight changes can yield unexpected (and often positive) results. In these particular cases, the modifications were made to website elements.

Changes to the ‘total look’ Idle screen displays, resulted in a 51% increase in interaction rate. Source.

Implementing the softer call-to-action on the ‘our vehicles’ pages – increased the number of leads by 46%. Source.

With introduction of the weekly target progress bar, the average size of single donations increased by 51%. Source.

Connect with me on LinkedIn