DEV Community: Mariana Caldas

How Large Language Models (LLMs) actually work

Mariana Caldas — Thu, 30 Oct 2025 01:29:50 +0000

In the first article of this AI series, Why AI struggles with “no” and what that teaches us about ourselves, we explored how language models often misinterpret negation and how those mistakes mirror some very human learning patterns.

In this new piece, we’re going a step further, trying to draw a clear line between human and machine intelligence while answering the following:

Are today’s language models really intelligent in the way we are? Do they reason, reflect, and create from scratch?

The short answer? No.

Language models can sound equally inspired, but their creativity is different. They don’t create from meaning; they predict patterns. When you see an impressive AI-generated paragraph, what you’re reading is the result of billions of statistical predictions that mimic the structure of human expression. The illusion feels real because prediction and creativity share a similar surface: both produce something new from something known.

That difference between meaning and mimicry is what we’ll explore next. The final goal is to help you feel more confident using those incredible tools.

Human intelligence vs. machine prediction

Human intelligence is semantic (we interpret, connect, and assign meaning), while machine intelligence is syntactic; it manipulates form rather than meaning.

When humans create, we draw from more than stored words or patterns. We rely on a lifetime of experiences, emotions, and associations that shape how we express ideas. Our creativity often comes from combining unrelated thoughts or memories into something entirely new.

Psychologists describe this reflective process as System 2 thinking: slow, deliberate reasoning guided by awareness and meaning. It’s what we use when solving problems, making ethical judgments, or forming original connections between ideas.

At least for now, machines don’t do that.

Large Language Models (LLMs) like ChatGPT (by OpenAI), Claude (by Anthropic), Gemini (by Google DeepMind), and Llama (by Meta AI) operate through System 1-like behavior: fast, automatic, and predictive. In a nutshell, they don’t think; they predict what comes next based on patterns found in massive amounts of training data.

Every response you read from an LLM is the result of statistical pattern-matching. It looks at billions of text examples and estimates which token (a fragment of a word or symbol) is most likely to follow your prompt. That’s why these models can sound fluent, even brilliant, without truly understanding what they’re saying.

A study from MIT CSAIL (2024) showed that reasoning skills in large language models are often overestimated. They perform well on familiar tasks but fail when the scenario changes.

Similarly, From System 1 to System 2: A Survey of Reasoning Large Language Models (2025) explains that while models can imitate human logic through learned patterns, they rarely achieve the deliberate, abstract reasoning that defines human thought.

Another paper, Evidence of interrelated cognitive-like capabilities in large language models (2023), reinforces this: the models exhibit behaviors that look intelligent but are still driven by correlation, not comprehension.

Now that we’ve differentiated how humans and LLMs reason, let’s look at how these remarkable systems actually process information and how understanding that can help us get the best out of them.

Short-term memory convos

Every interaction with an AI model is built on tokens, tiny pieces of language that represent words, parts of words, or punctuation. Tokens are how the model processes and predicts what comes next in a given sentence.

For example, the sentence “This is how LLMs break up language” contains nine tokens on the OpenAI GPT-4 Tokenizer. Most English words average about ¾ of a token.

Now, each model has a limit on the number of tokens it can “see” at once. This limit is called the context window, and it works as the model’s short-term memory.

GPT-3.5 handled around 4,000 tokens.
GPT-4 Turbo and Claude 3 Opus expanded that to roughly 128,000.
GPT-4.1 and GPT-5 can now manage up to one million token s.

This expansion allows for long conversations, uploaded documents, and even book-length inputs, but it’s not true memory. Once the window fills up, earlier information is compressed or replaced. The model can’t recall those details unless they’re reintroduced, which explains why AI sometimes contradicts itself or loses track of context: it has simply run out of space to “see” what came before.

Complex instructions, such as those involving negation (“don’t do X unless Y”), also depend on this limited window. If earlier details fall out of view, the model might miss conditions or reverse logic.

The tip here is: when writing prompts, keep instructions focused and reintroduce context when needed. It’s like talking to someone who is taking notes in real time. If you want accuracy, repeat the key points.

Chunking and Retrieval-Augmented Generation (RAG)

Behind the scenes, when an AI model reads a long piece of text, it doesn’t process it all at once. Instead, it breaks the text into smaller pieces called chunks, each one fitting neatly within its context window. This internal process helps the model manage information efficiently without losing track of meaning.

However, when you provide external data, such as uploading a PDF, website links, or connecting to a database, the model needs a way to access it. That’s where Retrieval-Augmented Generation (RAG) comes in.

RAG is an external method that allows a model to retrieve relevant information rather than rely solely on what fits within its window. When you ask a question, the system searches your documents for related sections (chunks) and gives that content back to the model to generate a grounded, more accurate answer.

In short, chunking is how the model processes what’s already inside, while RAG helps it reach outside its memory limits to access knowledge it doesn’t currently hold. Together, they help balance speed, scale, and accuracy.

You can make both processes more effective by preparing your data clearly. Use short sections, descriptive titles, and simple summaries when sharing documents. The better organized your material, the easier it is for the model to retrieve what matters.

Wrapping up

LLMs have changed how we write, learn, and create, but understanding how they work changes how we use them.

They don’t think like humans; they predict patterns based on probability, and when we understand how those patterns are built (through tokens, context windows, chunking, and retrieval), we can guide them more intentionally.

We could say, then, that:

Clarity helps them stay logical: the model only works with what it can “see.” Clear prompts reduce confusion and keep its short-term memory focused.
Structure helps them stay consistent: chunking and retrieval rely on well-organized information to produce coherent results.
And our intent gives their output meaning: while models predict patterns, only humans can add context, emotion, and purpose.

In the end, AI doesn’t replace human creativity or intelligence; it extends it.

Is it fair to fear AI?

Mariana Caldas — Fri, 12 Sep 2025 04:04:31 +0000

Every great invention has carried both wonder and fear. The printing press spread knowledge but also propaganda. The internet connected the world but also created new ways to exploit and divide it.

AI sits in that same lineage. It sparks fascination with the promise of medical breakthroughs, climate solutions, and new forms of creativity. At the same time, it raises alarms about misinformation, job loss, and the possibility of systems we can’t fully control.

The big difference now is scale.

When the printing press emerged, adoption took centuries. Electricity spread over decades. Even the internet, though fast, rolled out unevenly. Because of globalization and digital infrastructure, a breakthrough in one lab today can impact millions tomorrow. That speed and reach make both the risks and opportunities harder to contain or ignore.

Both reactions, fear and excitement, are justified. Fear acts as a compass pointing to where risks lie, while excitement is the energy that drives discovery. In this article, we will reflect on why the real work is learning how to carry both at once and to design AI with engines that move us forward and brakes that keep us safe.

Reasoning the fear

“AI fear is a response to speed and scope colliding in ways humanity hasn’t faced before.”

AI fears aren’t abstract; they’re grounded in what people already see. Algorithms already shape who gets hired, who receives loans, and how information spreads. In the past, the consequences of new technologies were often limited by geography. A printing error might mislead a city; an electrical fault might black out a neighborhood. With AI, a flaw can propagate globally in seconds, replicated across platforms and industries before anyone notices.

This scale amplifies existing worries:

The feeling of losing control when decisions are made by systems that most people don’t fully understand.
The concentration of influence when only a few actors hold the keys to the most advanced models.
The unease of watching machines step into not just repetitive labor, but creative and professional spaces that shape identity and purpose.
The erosion of trust as misinformation spreads faster than fact-checks can keep up.
And finally, the existential unease that even low-probability risks matter when the reach is this vast.

Balancing excitement with caution

If fear is amplified by speed and scale, so is excitement. The very qualities that make AI risky—its ability to learn, adapt, and spread quickly—are also what make it powerful. A system that can connect patterns across domains doesn’t just disrupt jobs; it can accelerate cures, design new materials, and help stabilize fragile ecosystems.

The temptation is to either sprint forward blindly or freeze in panic. But history shows us that progress paired with restraint is what creates lasting value. Electricity didn’t become transformative until we invented standards and safety codes. The internet didn’t become usable until we learned to build protocols and firewalls. With AI, the “brakes” we design now will decide whether its engines move us toward collective progress or collective harm.

That balance requires a mindset shift: building for resilience, not just speed. It’s not enough to launch faster models. We need oversight that can keep pace, transparency that makes the invisible visible, and social systems flexible enough to absorb disruption without breaking.

The skills and brakes we’ll need

“Together, these skills and breaks form the toolkit for resilience. Without them, engines run unchecked. With them, we have a chance to shape where we’re headed.”

Unlike past inventions, AI doesn’t give us decades to adjust. Its scale forces us to build engines and brakes at the same time, and that means different kinds of expertise working together from day one.

Technical builders are the ones who can turn “black boxes” into something interpretable. The brake here is interpretability, which means code and tools that let humans question the machine before acting.

A practical scenario: The engine can be represented by an AI model that detects patterns in scans that a human eye would miss, offering earlier diagnoses and potentially saving lives. But the brake matters just as much: every AI-generated recommendation must still pass through medical professionals who can weigh context, ethics, and patient history. Without it, one flawed update could spread misdiagnoses worldwide overnight.

Lawyers and ethicists turn abstract values into enforceable standards. The brake here is accountability: clear rules that force organizations to explain and defend automated decisions, just as we expect food or medicine to meet safety codes.

A practical scenario: In hiring, the engine is an AI system that can screen thousands of resumes in hours. But without accountability, that same system can quietly filter out women or minorities at scale. Audit trails and appeals are the brakes that keep bias from being locked into code.

Economists and labor experts keep disruption visible. The brake here is preparation—retraining programs, transition funds, and new models of social support designed before jobs vanish, not after.

A practical scenario: The engine could be AI tools producing marketing copy or legal briefs in seconds. But that efficiency could hollow out industries overnight. Preparation through reskilling initiatives and income transition programs can soften the shock and help workers adapt instead of collapsing into unemployment.

Psychologists and sociologists map the invisible shifts in trust and identity. The brake here is awareness, which means guidelines and education that help people navigate blurred boundaries.

A practical scenario: The engine is a chatbot designed to reduce loneliness. For some, it works. For others, it deepens dependency, blurring the line between authentic human connection and simulation. Awareness campaigns and mental health frameworks act as brakes, ensuring tools meant to support don’t quietly harm.

Communicators—teachers, journalists, artists—make the invisible visible. The brake here is translation, turning technical complexity into language and imagery that people can understand and respond to.

A practical scenario: The engine is AI-powered predictive policing, pitched as a tool for safety. Without translation, communities may never see the biases embedded in the data. By surfacing those biases in clear language, communicators create the space for public debate and resistance.

And everyday citizens are not just passive recipients of AI; they’re the first to notice when something is off. These lived experiences are brakes too that alert the rest of us before harms become systemic.

A practical scenario: The engine is an AI scheduling system rolled out across a retail chain. It boosts efficiency but leaves workers struggling with unpredictable hours. Employees themselves—sharing experiences with unions, co-workers, or the public—will apply the brake by forcing accountability and adjustments.

Fear as compass, excitement as fuel

And in the midst of uncertainty, I invite you to start seeing fear and excitement not as opposites, but as partners. I also invite you to imagine a future where this balance works: doctors supported, not replaced, by transparent diagnostic tools; workers retrained before industries collapse; children learning with AI tutors but guided by teachers who keep curiosity alive; climate models open and accountable, driving collective action instead of private gain. That’s what engines and brakes together can look like.

If humanity gets this right, AI could become a partner that amplifies our better side and helps us protect the beauty of the world we share.

What do you think?

Do you feel more fear or more excitement about AI right now? And how do you think society can adapt to its increasingly global and fast-moving scale?

Please drop your thoughts in the comments. I’d love to hear your perspective!

Talk soon, and take care.

Getting your product to the right people

Mariana Caldas — Sun, 03 Aug 2025 04:50:10 +0000

And here we are in the final article of the product management lifecycle series, inspired by the Stanford course, "Product Management: Transforming Opportunities into Great Products." In this series, we’ve been walking through the product lifecycle, not just from a theoretical standpoint, but through the lens of what it takes to bring ideas to life in a way that makes sense for users, teams, and businesses.

A recap of what we’ve covered so far:

We now arrive at the final core phase in the product lifecycle: Go-to-Market (GTM).

If launching is the first conversation with our users, then GTM is what keeps that conversation going and helps the right people hear it.

What is Go-to-Market?

Go-to-Market is not just a distribution plan; it’s a cross-functional strategy that defines how your product reaches and retains the right users. It includes product design, positioning, pricing, messaging, customer support—and yes, distribution too.

In the course, GTM was defined as the process of reaching customers in a way that makes acquiring and serving them both viable and effective. That means understanding not only how people will find your product but also whether your business can sustainably support and grow with them.

Here’s a quick comparison to ground it:

Take a mental health app built for working parents. If research shows they trust parenting influencers more than app store ads, your GTM might involve co-creating content with those influencers, streamlining onboarding for busy schedules, and offering family-centric pricing. And if those same parents tend to hear about tools through pediatricians or community groups, your GTM may need to start by establishing partnerships or referral networks with those sources.

Three components of every GTM plan

The Stanford framework breaks GTM into three interconnected pillars:

Your product — What are you offering, and what makes it uniquely valuable?
Your customer — Who are you targeting, and how do they buy, learn, and use products?
Your economics — What are your margins, and what can you afford to spend on reaching and retaining users?

Let’s bring this to life with a few scenarios:

If you're building payroll software for small teams, your product might be self-serve, your customer is likely a non-technical HR manager, and your margins can’t support a full sales team. Your GTM may rely on SEO landing pages, free trials, and short demo videos.
If your product has a high customer lifetime value (LTV)—such as Workday, with its enterprise contracts—you can afford a long sales cycle and a human-led sales team.
If you’re Dropbox, trying to convert individuals with low LTV into paying users, you’ll likely depend on low-cost strategies like referrals or freemium upgrades.

Each decision, from pricing to onboarding, flows from this Product-Customer-Economics triangle. It helps you understand what tactics are viable, and what’s likely to stretch your resources thin.

Aligning GTM with product economics

Let’s delve deeper into the economic point to understand its metrics and establish your plan while protecting your profit margins.

LTV (Customer Lifetime Value): the total revenue a customer brings over time.
CAC (Customer Acquisition Cost): how much you spend to acquire each customer.

Your GTM strategy is only viable when CAC is significantly lower than LTV. A healthy ratio is often 1:3 or better.

For example, if your LTV is $300, you can’t afford a $250 CAC—you’ll burn money with every user. However, if your LTV is $30,000, a higher CAC is acceptable, and GTM efforts, such as demos, onboarding support, or even direct sales, are sustainable.

Matching channels to customer types

The course breaks down GTM motions by customer type:

B2C (Consumer): Prioritizes reach and simplicity. Think referral programs, viral content, and intuitive onboarding.
SMB (Small Business): Blends self-serve flows with just enough support. Think product-led growth, webinars, and email nurtures.
Enterprise: Involves high-touch sales, security reviews, and internal enablement. The GTM focus here is helping internal champions make the case.

The lesson here is alignment. If you're designing for enterprises but expecting B2C-style organic growth, you're likely to hit friction in adoption, retention, or scalability.

When the product becomes the channel

Sometimes, your best GTM tool is the product itself. Hotmail did it with one line at the end of every email: “Get your free Hotmail account.” Dropbox gave users free storage for inviting friends. PayPal paid users to sign up and send money.

More than “Marketing hacks”, those companies leveraged design choices that enabled distribution from the inside out.

Whether through shareable moments, in-app prompts, or embedded use cases, this kind of growth tends to be the most scalable and often the most delightful.

💡 Tip: Ask yourself: “How could this product help users discover or share it without needing a campaign?”

Final thoughts

This course takeaway has stayed with me:

Distribution is not a post-launch activity. It’s a product design choice.

When we align pricing, positioning, and onboarding with how people first hear about us—or how they expect to experience value—we’re building GTM into the product, not bolting it on later.

It’s easy to label this as something “Marketing handles”, but when GTM fails, it’s often because early product decisions weren’t aligned with the business model or customer journey.

I also want to note that Go-to-Market isn’t the end of the product lifecycle; it’s what connects everything that came before to everything that comes next while making growth sustainable, learnings repeatable, and outcomes visible. It’s where product and business intersect and where your team’s intentions (to help, to solve, to delight) meet the reality of reaching people and growing responsibly. So, GTM turns strategy into traction.

As this series comes to a close, I hope the core message has been clear:

Product Management requires understanding how each phase informs the next and how each decision builds momentum for the ones that follow.

Thank you for reading, learning, and hopefully building alongside me.

Talk soon, take care.

Launching as the beginning of a conversation

Mariana Caldas — Thu, 03 Jul 2025 00:52:09 +0000

Over the past few months, we’ve been talking about product management through the lens of the Stanford course, "Product Management: Transforming Opportunities into Great Products". In this series, I’ve been unpacking key ideas from the course and connecting them to my experiences as a product manager: what resonates, what shifts your perspective, and what helps build better teams and products.

So far, we’ve covered:

Now we’ve reached a moment that often gets treated as a milestone, but is actually a starting point: launching.

What does it mean to launch?

"It’s more than just shipping code; it's learning how the product lives in someone else’s hands, in their actual workflow."

A launch is commonly thought of as the final step in delivery, but that view is incomplete. Launching marks the first time your product interacts with users beyond your immediate circle. It’s when internal work becomes external reality.

In the course, the concept of a launch was reframed as a transition—from building something to helping it land. That shift demands not only technical readiness but also user clarity.

A clear Beta is often more valuable than a rushed GA

Launch is not just a release; it’s the beginning of a learning process. Beta, in particular, is your chance to see how people use what you built, without assuming they’ll figure it out. That feedback is essential before going wide.

That process usually unfolds in three stages:

Alpha: Shared with close collaborators and internal testers. Feedback is qualitative and focused on the general direction.
Beta: Shared with real users who actively opt in. This is where patterns emerge, confusion shows up, and assumptions get tested.
General Availability (GA): The public version. At this point, your product needs to carry its own message, without someone standing beside it to explain.

Skipping Beta in the name of urgency often means learning the hard way, in front of a broader audience. For example, imagine launching a redesigned onboarding experience without Beta testing. What looks intuitive to your team might leave users stuck on the first screen. Beta gives you a space to see where people hesitate and adjust before it hurts adoption.

If the team isn’t aligned, the user won’t be either

The course introduced a framework for assessing launch risk based on two factors:

How big is this change?
Can we walk it back?

Large, irreversible changes (like pricing or platform shifts) require strong internal alignment across all functions. Even small, reversible changes can create confusion if the team isn’t on the same page about what’s being released, why it matters, and how it should be presented.

Examples

Let’s say you're changing a subscription pricing model. That’s a significant and probably irreversible change as it affects revenue, user trust, and long-term retention. It requires not only technical implementation but also coordinated messaging, clear FAQs, and alignment between Product, Marketing, Sales, and Support.

On the other hand, changing the color of CTA buttons is a minor and reversible change. However, even then, if Marketing promotes an outdated screenshot, confusion can still creep in.

That’s where internal readiness comes in. It’s a concept that refers to internal alignment about the following:

The product works as intended.
Documentation is done and accessible.
Support knows what might generate questions.
Sales and marketing have a consistent narrative.
The whole team agrees on how success will be measured.

"One process that’s worked for me is running a short cross-functional 'launch readiness' meeting before every GA release. It includes Product, Support, Marketing, and Sales. Everyone brings their checklist: FAQs, updated documentation, messaging drafts, and any last blockers. This meeting ensures we all know what’s going out, how we’ll talk about it, and who owns the follow-up if things go wrong."

In my experience, the fastest way to create external confusion is to let internal uncertainty slip past the launch date.

Launch content should be written for users, not for internal validation

“If your content only makes sense to people inside the building, it’s not ready to go out.”

A launch post, email, or in-product message isn’t an internal announcement. It’s how users first encounter what you’ve built. That means that launch materials are not accessories, but part of the product itself.

Good launch content answers three things clearly:

What’s changing?
Why does it matter to me?
What can I do with it right now?

A great example we explored was Airbnb’s blog post about profile photo changes. It starts from the user’s perspective, grounds the update in real feedback, and communicates just enough to inspire confidence and understanding.

The trick is to write as if you’re speaking to someone who has never seen the product before and needs to decide in one minute whether it’s worth exploring.

Simple videos help people get started faster

Another principle I’ve taken forward is the power of short, helpful walkthroughs. Video is one of the most underused assets in a launch. I encourage you to build quick, user-facing demos that show the product in context, even if they’re rough.

A short video can:

Show how to use a new feature, instead of explaining it abstractly
Humanize the launch
Reduce early support tickets
Create internal alignment on what’s actually shipping

In one example, Uber and Figma used video testimonials to tell the story of how a new organizational feature helped real teams. It wasn’t overly produced—it was relatable. That’s often more persuasive than the perfect copy.

A quiet, effective launch often performs better than a noisy one that misses the mark

Since launches are critical moments where many things can change, we definitely benefit from seeing them as transitions to be supported, rather than moments to be maximized. In other words, don’t confuse a launch with a one-time announcement. It’s a period of onboarding, feedback, adjustment, and messaging consistency. The goal isn’t to be loud—it’s to be helpful.

That transition depends on external readiness:

Are users aware of what’s changed?
Can they quickly understand the benefit?
Are we prepared to support the feedback and questions that follow?

This is true whether you’re releasing new UX for a form or introducing a new service tier. Some launches benefit from scale and visibility. Others benefit from focus and stability. But in either case, what matters most is whether people understand and use what you’ve released, not how loud the campaign was.

A launch is part of the product

"Launching is a Product decision, not a Marketing one."

This was one of the most important mindset shifts in the course: launching is a product decision, not a marketing one. When a launch is reduced to a deadline or a campaign, we risk ignoring its most critical function: delivering value.

That means:

It should be designed intentionally.
It should reflect user context and needs.
It should have its own success criteria.

Skipping this work risks wasting the opportunity created by months of development. If we get it right, the launch becomes the moment when our product starts delivering real value.

When launch becomes an afterthought, you may end up with a strong feature that fails to gain traction simply because no one knew what to do with it. That’s a loss not just for the business, but for the users who never got to benefit from it.

Wrapping up

A thoughtful launch goes beyond checking boxes or maximizing attention; it’s meeting the user where they are and making the transition into your product feel obvious, helpful, and worthwhile.

When we take the time to stage launches through Beta, align internally, clarify the message, and offer a simple walkthrough or two, we make the product stronger. And when we treat the launch as part of the Product, not something layered on top, we start to build trust from the first interaction.

Launches can spark momentum, but momentum isn’t scalable. The final article in this series will explore how we make products discoverable, repeatable, and sustainable, so that value doesn’t just begin at launch, it continues to grow. Do you know which phase I'm referring to?

Talk soon, take care.

Why AI struggles with "no" and what that teaches us about ourselves

Mariana Caldas — Fri, 23 May 2025 23:32:21 +0000

Over the last few months, I’ve been building some pretty layered automation using Zapier, Ghost, PDFMonkey, and Cloudinary, guided step by step by ChatGPT, and it’s been... eye-opening.

I think AI is the best assistant ever when exploring possibilities to solve a problem, but it occasionally fails in ways that feel surprisingly human. As a former teacher, I’ve come to appreciate two patterns—two things large language models consistently struggle with—that have deep roots in how people think and learn.

Let’s break them down.

1. Negation is hard for both humans and machines

One of the most common mistakes I’ve seen ChatGPT make is with “negative commands.”

For example, I once said:

“Don’t overwrite existing tags unless the user doesn’t have any.”

The result? The tag was overwritten, even when it shouldn’t have been.

Why? Because large language models don’t “understand” logic like a programmer. They predict the most likely sequence of words based on examples from their training data. When phrasing is complex or wrapped in multiple negations, models often pick up on the structure of the sentence without truly grasping the logic.

This is where it gets human.

Children, especially infants and toddlers, also struggle with negative commands. Telling a 2-year-old, “Don’t touch that,” often leads to… them touching it.

Why? Because understanding “don’t” requires holding two ideas in mind:

What the action is (“touch that”)
That it should not be done

Developmental psychologists have studied this for decades. A classic source is:

Pea, R. D. (1980). “The Development of Negation and Its Role in the Construction of the Self.” Cognitive Science

Even adults process negative statements more slowly and with more errors than positive ones.

This parallels how LLMs “misread” complex negation—they’re great with surface forms, but logic wrapped in linguistic twists? That’s still a blind spot.

2. Memory gets fuzzy when things get long

Here’s another pattern: long conversations with ChatGPT often lead to inconsistent behavior.

You’ll say something, set up a rule, get it working, and 20 minutes later, the AI starts forgetting the rule or contradicting something it already confirmed.

Why?

Large language models have a limited “context window.” GPT-4 can look at many tokens (~128k words at most), but the longer the conversation, the more compressed and imprecise that earlier information becomes. It’s like trying to summarize 40 pages of notes and then recall just one detail from page 4—you might miss it.

OpenAI describes this in its technical report on GPT-4: memory is not long-term; it's a temporary window.

Again, this echoes human learning.

When we overload working memory, especially without structured reinforcement, information decays. Educational research shows that our brains retain new concepts best through spaced repetition, simplified input, and direct reinforcement.

Long chats with no clear breaks? That’s like reading 12 chapters of a textbook in one night and hoping it all sticks.

3. “Structured memory” sounds great — but here’s the real story

One thing I wanted to figure out was how to help ChatGPT remember key info across different workflows. At first, I assumed the new Projects feature meant each workspace had its own memory. Not quite.

Here’s how it really works:

ChatGPT’s memory is global, not project-specific. If memory is on, it might remember something you told it (like your name or that you're working on a Ghost theme), but it doesn’t organize those memories by project.

The Projects feature is amazing for keeping chats and uploads organized, but memory isn’t isolated to one project versus another.
If you go to Settings → Personalization → Manage Memory, you can see what it remembers and delete specific entries—but it’s still one big pool of memory.

So, how do you carry memory across projects?

There’s no native way to export memory and plug it into a new project. But here's what I’ve been doing that actually works:

Export your chat history: Go to Settings → Data Controls → Export Data and you’ll get a ZIP with all your chats.
Save useful logic and notes from past chats into a document.
When starting a new project, upload that document or paste in key info. ChatGPT will use it during that conversation—even if it doesn’t "remember" it forever.

It’s not real memory, but it’s a repeatable way to simulate it.

What it teaches us

This is what I love most: these quirks in AI aren’t just bugs—they’re mirrors.

When LLMs trip over negation, they reveal how language is more than structure—it’s logic in disguise, and logic is never as simple as it looks. When their memory fades, they remind us that attention, reinforcement, and structure matter—not just for machines but also for our own learning.
When we build systems that help them remember better, we’re also uncovering what we need to organize complexity in our own minds.

What I’ve learned

Here’s what’s helped me when working with AI (and people, frankly, haha. 🫠 ):

Say what you want to happen—avoid phrasing in terms of what not to do
Keep logic simple and sequential
Break long workflows into smaller steps or shorter conversations
Use memory intentionally—don’t expect it to hold your entire logic stack indefinitely
Leverage a project-based organization to simulate long-term context

And maybe the biggest lesson?

AI and humans remember things in very different ways.

For us, memory is layered—it’s shaped by emotion, context, repetition, and meaning. We don’t just recall facts; we hold on to stories, mistakes, and feelings. We forget when we’re overwhelmed, but we remember what touches us deeply.

ChatGPT’s memory, by contrast, is more like a list: detached, structured, and factual. It forgets by default unless told otherwise, and it doesn’t “feel” the past.

And yet, watching how AI handles memory—where it helps and where it fails—has taught me a lot about how my own memory works, too:

We need clarity and repetition.
We remember better when things are meaningful.
And just like AI, we benefit from structure, but we add our own human layers on top.

In the end, these tools don’t just assist us, they reflect us.

If this topic resonates with you, I highly recommend watching this short talk:

As the video highlights, we’re not just using AI; we’re working with it, learning alongside it, and shaping what it becomes while reflecting on who we are. If that’s not creativity, I don’t know what is.

Want to go deeper?

I’m thinking about writing a short series on how large language models really work and what that means for everyday people using AI in their projects.

Would that interest you? Leave a comment and let me know. If there’s interest, I’ll dive in 🥽. Talk soon, take care.

It’s product-building time, baby!

Mariana Caldas — Mon, 21 Apr 2025 18:27:09 +0000

In our Web Dev Path product management series based on the Stanford course Product Management: Transforming Opportunities into Great Products, we've talked about the importance of identifying user problems, designing thoughtful solutions, and crafting a product vision that aligns business goals with user needs. Now, it's time to turn those ideas into something tangible: we build.

The build phase is where the vision starts to materialize—where all the research, alignment, and ideation converge into a first version of the product. But this phase is more than just execution. It’s where clarity turns into momentum, and where product managers must balance speed, focus, and adaptability.

Vision vs. Product: What are we building?

We already know that the product vision translates the company’s mission into an actionable blueprint. But in the build phase, it’s worth zooming in on one key idea:

A product is only successful if it stays true to the vision while adapting to real-world constraints.

This is where alignment becomes critical. Each line of code, each feature shipped, should move us closer to the future we’ve committed to creating. If your product vision emphasizes transparency and trust, then what you build— and how you build it —must reflect those values. This includes aspects such as how data is handled, the onboarding experience, and how content is personalized.

For PMs, this means checking in constantly: Is what we’re building consistent with our vision? Or are we prioritizing what’s easy to ship over what actually matters?

The answer to those questions should guide how we define our Minimum Viable Product (MVP).

The Minimum Viable Product (MVP)

An MVP is not a half-baked product. It’s the smallest version of your solution that delivers real value to your target users and helps you learn something meaningful from a quick testing phase with user validation through surveys and user experience sessions, for example.

Your MVP should:

Solve a clear and validated problem.
Deliver one strong core feature that reflects your vision.
Be measurable so that you can quickly assess your success.

Tip:

Avoid bloating your MVP with assumptions disguised as must-haves. Instead, focus on what gets you the highest learning return for the lowest build cost. If you can’t clearly explain the problem your MVP solves and what you’re testing, it’s probably not minimal or viable.

How do we measure what we’re building?

Building a product without tracking whether it works is like flying blind. That’s where metrics and, more specifically, OKRs (Objectives and Key Results) come in.

Here’s how metrics support the build phase:

They align the team around what success looks like.
They help you prioritize what to build first.
They provide early signals to validate (or invalidate) your assumptions.

Let’s break that down. Start by setting a clear objective, which is the desired outcome for your users or business. Then, define 3–5 measurable key results that indicate whether you’re on track. These aren’t just aspirational—they should be quantifiable, realistic, and time-bound.

Example: a dating app feature that assists users in filling out their profiles

Objective: Help users feel more in control of their online dating experience.
Key Result 1: Increase profile completion rate from 50% to 90%.
Key Result 2: Increase match numbers by 30% due to more complete profiles.
Key Result 3: Reduce profile editing churn (users who abandon mid-way when they find the process boring or too complex) by 40%.

Once your OKRs are in place, you’ll want to track them using lightweight dashboards or tools like:

JIRA dashboards (paired with sprint goals),
Google Sheets or Notion (for early-stage products),
Product analytics tools, such as Mixpanel, can be used to monitor user behavior in real-time.

Tip:

Pair quantitative metrics with qualitative feedback. A rise in profile completion is great, but hearing why users finished their profile (or didn’t) through user interviews or surveys is what brings context to the numbers.

Whether you’re using OKRs or another framework, the principle remains the same: build with accountability. Metrics ensure you’re solving the right problem the right way, with evidence to back it up.

What is the PM's job in this phase?

During this phase, the PM serves as a translator between the strategic and tactical levels. You’re not here to micromanage, you’re here to keep the team aligned, empowered, and unblocked. You’re also responsible for keeping the product cohesive, ensuring that each feature connects to the overall product strategy, rather than becoming a scattered list of to-dos.

Here’s how you show up:

Clarify the “why”—every sprint, every ticket, every iteration should map back to your product vision.
Unblock the team—whether it’s cross-team coordination, late decisions, or shifting priorities.
Hold the line on quality—not in a perfectionist way, but to protect user trust.
Keep the energy up—acknowledge wins, protect focus, and yes, sometimes bring the donuts.

An experienced Product Manager knows that structure enables creativity. During the build phase, systems such as sprint planning, QA gates, retrospectives, and feedback loops (thanks, well-applied Scrum Agile!) help keep the team moving in sync.

These systems create clarity on what’s next.
They ensure velocity without chaos.
And they give everyone confidence that the product is moving in the right direction.

The build phase is also when we start thinking about what comes next—the launch. But we’re not there yet.

What’s coming next: launch types and go-to-market

Once your MVP is ready, the next natural step is to get it into the hands of users. But not all launches are the same. In our upcoming articles, we’ll cover:

Different types of product launches—from soft beta rollouts to full public releases.
How to design a thoughtful go-to-market (GTM) strategy that drives adoption and closes the loop on your product lifecycle.

This is the final stretch of the Stanford course—and it’s where all the upstream thinking pays off.

Final thoughts: build with clarity, test with intention

If defining the product vision gave you the blueprint, then building is where you lay the foundation. And just like any structure, what you build now will shape everything that comes next, so it pays to be intentional.

Focus on solving the core problem. Use metrics to keep your eyes on the outcome. And empower your team to build something meaningful, not just shippable.

Talk soon, take care, and get ready to launch 🚀

Defining the product vision

Mariana Caldas — Mon, 17 Feb 2025 21:21:53 +0000

Hey, community! It’s time to talk about the importance of understanding the product vision to help our teams make the best decisions when creating a new product or extending its reach with new features.

A clear product vision is like a compass in product development. Over time, I’ve discovered that it’s not just about a catchy statement—it can be turned into a guiding framework that helps every decision, every feature, and every iteration stay true to the core value we want to deliver.

What is product vision?

Before we dive in, let’s clear up any confusion: while company vision is the broad, overarching goal that shapes the entire organization, product vision is a focused, actionable blueprint for a specific product. In essence, the product vision takes the company's big-picture aspirations into concrete plans that drive every decision, feature, and iteration.

Product vision is the strategic guide that answers two essential questions:

Why does this product exist?
What value does it deliver to our users?

This clarity anchors your team’s efforts, ensuring every decision is aligned with solving a real user problem.

The product vision framework

I find it helpful to break down product vision into five detailed elements. Each one plays a role in shaping the product’s direction:

Problem

Begin by defining who you’re serving—the persona—and pinpoint the specific challenge they face.

Imagine community organizers (persona) who need timely, culturally relevant information to coordinate events (problem).

Solution

Outline what a Minimum Viable Product (MVP) would look like to address that problem directly.

A basic dashboard that aggregates and displays real-time community updates. This initial version should serve as the foundation for further enhancements.

Improvements

Envision additional features that could expand on the MVP over time.

As the product matures, you might layer on customizable notifications or predictive analytics to better anticipate community needs.

Trade-offs

Consider the necessary compromises by balancing security, performance, and cultural sensitivity.

A geolocation feature might promise localized content delivery. However, if it restricts access in a way that frustrates users, those trade-offs must be carefully weighed.

Wild ideas

Leave room for bold, innovative thinking that challenges the status quo—ideas that might seem unconventional at first but could redefine your product’s potential.

Experimenting with AI-driven personalization may start as a conceptual idea but can eventually open entirely new avenues for user engagement.

Product vision in action

Let’s examine two contrasting real-case scenarios I’ve experienced as a product manager that show why a well-defined product vision is essential.

Case 1: The geolocation misstep

The idea:

A product team set out to boost content relevance by developing a geolocation-based feature. The idea was to restrict access to specific content based on a user's location to ensure that only the most relevant audience could engage with it. The goal was to create a more personalized experience, ensuring that sensitive or context-specific information was only visible to those within a designated area.

What went wrong:

While the team correctly identified the problem—making content more relevant by tying it to physical locations—they didn’t account for how different users would perceive the restriction.

For some users, the feature made perfect sense. However, for others, it felt like an unnecessary barrier, blocking them from accessing content that was previously available to them. This misalignment stemmed from not fully understanding the cultural and practical expectations of their target users. In communities where shared knowledge and open access to resources are highly valued, the restriction unintentionally created frustration and disengagement.

Without a comprehensive product vision that accounted for user context, cultural sensitivity, and accessibility needs (the personas' full picture), the feature failed to deliver the intended value. Instead of enhancing engagement, it alienated users who felt excluded from important content, weakening trust in the platform.

Case 2: The data integration overhaul

The Idea:

In another scenario, a team discovered that their method of connecting users to essential data was outdated and inefficient. They had an opportunity to rethink their API integration strategy.

What worked well:

Problem: The core issue was slow data access caused by an inefficient REST-based approach, negatively impacting user satisfaction.
Solution: Their MVP was a new integration model that streamlined data retrieval and improved performance.
Improvements: The vision allowed for future enhancements, such as stronger security measures and real-time monitoring as the product evolved.
Trade-offs: The team carefully balanced the need for performance improvements while maintaining data security and system stability.
Wild Ideas: They stayed open to exploring alternative technologies that could push performance even further.

This approach resulted in a measurable boost in performance and perfectly aligned with both user needs and business objectives—a clear demonstration of how a well-articulated product vision can drive success.

Final thoughts: see product vision as a blueprint.

Think of your product vision as a blueprint that empowers you to confidently say “yes” to initiatives that matter and “no” to distractions that deviate from your true objectives. Besides benefiting prioritization, being guided by a strong product vision will foster the following:

Alignment: It ensures every feature and decision supports the product’s core purpose.
Consistency: It keeps your team on track, even as market conditions and user needs evolve.

A well-defined product vision can be more than an abstract concept—it can become a practical framework that shapes every aspect of product development. By clearly identifying the problem, defining an MVP, planning for future improvements, weighing trade-offs, and daring to dream with wild ideas, you build a robust foundation for success.

What strategies do you use to ensure your product vision remains the guiding force in your projects? I’d love to hear your thoughts and experiences.

Talk soon, take care.

Designing the solution in product management

Mariana Caldas — Fri, 10 Jan 2025 23:03:49 +0000

In our Web Dev Path product management series guided by the Stanford program, Product Management: Transforming Opportunities into Great Products, we’ve been exploring themes such as the role of a Product Manager, the problem space, the product lifecycle and how to create roadmaps. Now, it’s time to move into the solution space, where creativity meets structure. This phase—designing the solution—is where product managers work with their teams to brainstorm, prototype, and identify ideas that balance desirability, viability, and feasibility.

Let’s break it down and dive into how we transform opportunities into thoughtful, user-centered solutions.

Divergence: generating ideas

The first step in designing the solution is divergence—creating choices and capturing a wide range of ideas. Divergence invites your team to explore possibilities and think creatively about how to address user problems.

Framing opportunities with "How might we"

“How might we” (HMW) statements are a powerful tool for framing opportunities and guiding brainstorming sessions. A good HMW captures the essence of the problem while leaving room for creativity.

Once you’ve crafted HMW statements, clustering ideas into themes aligned with user concerns ensures your brainstorming remains focused and actionable. For example, if users struggle with “authenticity” on dating platforms, themes might include profile personalization, user-to-user communication, or storytelling tools.

Example:

"How might we help well-educated professionals make more meaningful online connections?"

To refine HMW statements, consider:

Adding context from user feedback (e.g., “I don’t attract the kind of people I like on dating apps”).
Segmenting your customers for tailored insights.
Exploring follow-up questions to uncover additional perspectives.

"Emerging strong themes help identify possible solutions tied to user concerns."

The role of design constraints

Design constraints are truths about your customer, problem, or company that help narrow down solutions. For example, Ikea prioritizes affordability, while Tesla's early constraints focused on premium pricing and battery technology.

After defining your HMW statements, filter them through your constraints to prioritize what is achievable. On that matter, it’s important to understand the concepts of desirability, viability and feasibility:

Desirability (human): Does the solution address a genuine user need or desire?
Viability (organization): Is the solution aligned with the company’s business goals and financially sustainable?
Feasibility (technology): Can the solution be built with available resources, skills, and technologies?

So, when defining design constraints, ask yourself:

What is desirable for our users?
What is viable for our business?
What is feasible given our technology or resources?

Scenario:

"For a meal delivery service targeting urban professionals, desirability might mean offering fast and healthy options, viability could hinge on competitive pricing, and feasibility would depend on existing delivery infrastructure."

"The intersection of desirability, viability, and feasibility is where innovation thrives."

Convergence: prioritizing and testing ideas

Once you’ve created your ideas and filtered them through divergence, it’s time to converge—narrowing down the options and testing the most promising ones.

Testing solutions: Which ideas should be tested first?

After capturing a wide range of ideas during divergence, the next step is convergence, where you refine and prioritize the best options for testing. Focus on de-risking by identifying assumptions that could make or break your solution. Rank assumptions by uncertainty and importance.

Example of assumptions to test:

Do we have demand for this product?
Will users integrate this feature easily into their daily routines?
Are there technical or budget constraints?

Scenario:

"A language-learning app team might test whether users will pay for premium features and if reminders boost engagement or lead to app fatigue."

"The goal is to test assumptions cheaply and iteratively while maintaining quality."

Prototyping on a budget

Prototyping doesn’t have to be expensive. Tools like Figma, Adobe XD, and InVision allow teams to create high-quality digital prototypes quickly and at a low cost. Usability testing then validates whether the prototype works as intended.

Tips for usability testing:

Test with 5–10 users to capture diverse insights.
Remain neutral during sessions to avoid influencing responses.
Ask open-ended questions like:
- “What do you think this is for?”
- “What would you do next? Why?”

"Prototyping helps you de-risk while ensuring you don’t design something users might hate."

Working with design

Design represents the user's voice, while product represents the voice of the business. Together, these perspectives create the ideal product.

Collaboration with the design team should be iterative and user-centric by following some principles, such as:

Establish shared goals: Ensure everyone is aligned on the user problem and business objectives.
Iterative process: Share early drafts or low-fidelity designs with the team to gather feedback quickly.
User involvement: Run usability tests together to hear user feedback firsthand.
Clear roles: Define design, product, and engineering responsibilities to avoid overlaps and ensure efficient collaboration.

Case study: P&G’s Swiffer innovation

In 1994, P&G set out to generate $5 billion from new products. Their user research revealed cleaning pain points:

People changed into dirty clothes before mopping.
Mopping required sweeping first.
The process was messy and time-consuming.

Instead of creating another detergent, which is what other companies were doing, P&G reframed the problem as:

"How might we reimagine the tools we use to mop?"

This evolved into:

“How might we remove the step of sweeping before mopping?”
“How might we build a tool so users never have to touch dirt?”
“How might we create a mop that could attract dirt to itself?”

The result? The Swiffer launched in 1999 and generated over $100 million in revenue within four months.

"The best solutions emerge when user insights, constraints, and creativity intersect."

Overview of the Designing the Solution Process

Designing the solution requires balancing creativity with practicality. Here’s a recap of key takeaways:

Divergence:

Start with a clear user problem statement from the problem space (Evaluating Opportunity phase).
Create thoughtful HMW statements and cluster ideas into themes.
Establish design constraints to filter those ideas.

Convergence:

Identify key assumptions from the filtered ideas and test them first.
Use tools like Figma to prototype quickly and cheaply.
Involve users through usability testing to refine your solution.

Think about a challenge your team is currently facing. How might these approaches to divergence and convergence help you design a better solution?

Final thoughts

In product management, designing the solution is where the magic starts to happen. By balancing divergence and convergence, you ensure that creativity and user insights drive your solutions while practical constraints guide their execution.

Our following articles will dive into the next phases of the product lifecycle—building and shipping your product. Until then, let us know: What techniques do you use to generate and test ideas? Talk soon, take care.

Crafting stories that drive product success

Mariana Caldas — Wed, 01 Jan 2025 22:29:49 +0000

It’s time to talk about roadmaps in our project management blog series based on the Stanford course Product Management: Transforming Opportunities into Great Products. Roadmaps aren’t just documents for organizing tasks—they’re about telling stories. Stories that connect what teams do to why it matters, aligning efforts with a bigger picture.

One thing is clear about this essential document: great roadmaps balance customer value and organizational goals. They inspire action, provide clarity, and deliver measurable impact. Let’s break down how to build roadmaps that aren’t just plans but tools for growth and alignment.

What is a roadmap?

A roadmap is a living document outlining your product’s future. It communicates what you’re working on, why it matters, and the execution order. The best roadmaps prioritize effectively, delivering value to both customers and the organization as quickly as possible.

Value for customers: Solve the original problem identified in the problem space.
Value for the organization: Align initiatives with company goals and metrics.

As a product manager, your role is to prioritize impactful projects and ensure the roadmap reflects this balance. A key takeaway? Focus on problems that matter and avoid spending resources on less impactful tasks.

The foundation: developing themes

Themes are broad goals tied to solving specific problems and aligned with organizational priorities. Unlike a static Excel sheet filled with tasks and effort estimates or confusing Gantt charts, themes provide a dynamic framework that ensures clarity and focus. They tell a story of progress, aligning stakeholders with a shared vision.

What makes themes effective?

They focus on problems, not solutions: Themes articulate what needs to be addressed, leaving room for creativity in how to solve it. Example: Instead of "Build a user guide," use "Enhance onboarding experience."
They are measurable: Clearly defined outcomes allow teams to track progress and success.
Provide clarity: Anyone in the organization can understand what the organization wants to achieve by looking at the themes.

Example:

If the goal is to improve retention, themes could include:

Enhance onboarding: Increase onboarding completion rates by 20% in 6 months.
Reduce churn: Decrease monthly churn from 8% to 5%.

How are themes chosen?

Themes are derived from the intersection of customer needs and organizational goals, supported by qualitative and quantitative data. This can include user feedback, market research, and performance metrics.

Break themes into actionable projects

Once you have the broader vision, aka themes, it’s time to break them down into projects to make those big goals actionable.

How to break down themes into projects:

Identify initiatives that directly support a theme.
Ensure projects are specific enough to generate momentum but broad enough to make a significant impact.

Example projects for the theme "Enhance onboarding":

Create interactive onboarding tutorials.
Send personalized welcome emails.
Build progress dashboards for users.

Estimate impact, cost, and prioritize

Understanding impact and cost is crucial for prioritization. Techniques like T-shirt sizing (small = hours/days, medium = weeks/months, large = quarters/years) combined with Fermi estimation can help quickly approximate potential benefits. At the same time, past project data can guide cost predictions.

Example of estimating impact:

Problem: Increase adoption of a new feature.
Steps: Break down the problem into parts:
- Number of active users: 1,000,000.
- Expected adoption rate: 20%.
- Average usage frequency: 3 times per week.
Impact: 600,000 interactions weekly, contributing significantly to engagement metrics.

Pro Tip: Beware of the planning fallacy—things often take longer than expected. Combining data, judgment, and past project insights helps make informed decisions about which projects deserve priority.

Balancing the portfolio

With your goals (themes) and estimated projects in place, it's time to treat your roadmap as an investment portfolio. A healthy roadmap balances:

Short-term wins: Quick-impact projects that build momentum.
Big bets: Ambitious initiatives with long-term value.
Risk management: Diversifying efforts to mitigate potential failures.

Practical example:

The overarching theme here could be: "Enhance team productivity through collaboration and intelligent features."

Here’s how you might structure it using the "Now, Next, Later" framework:

Now (short-term wins):

Project: Introduce a live chat feature for real-time collaboration.
- Rationale: Addresses user feedback about the need for instant communication.
- Impact: High. Enhances the core experience.
- Cost: Medium. Requires integrating existing APIs.

Next (big bets):

Project: Implement AI-driven task recommendations to boost productivity.
- Rationale: Differentiates your product from competitors by leveraging advanced AI capabilities.
- Impact: High. Drives long-term user engagement and retention.
- Cost: Large. Involves significant R&D and infrastructure investment.

Later (risk management and exploration):

Project: Add integrations with third-party apps (e.g., time tracking and project management tools).
- Rationale: Broadens your ecosystem and attracts new user segments.
- Impact: Medium. Increases product stickiness but depends on user demand.
- Cost: Small. Requires validation and partnerships.

Why balance matters:

By combining these initiatives, your roadmap ensures immediate progress while investing in future potential. It also mitigates risk by preparing a pipeline of validated ideas for execution.

Bringing it all together

A roadmap is more than just a list of tasks; it’s a story that aligns your team around shared goals and measurable outcomes. You create a tool that inspires and drives meaningful progress by starting with clear, problem-focused themes, breaking them into actionable projects, and prioritizing them based on impact and cost.

Balancing your roadmap like an investment portfolio ensures short-term wins and long-term growth. Using frameworks like "Now," "Next," and "Later" helps keep priorities clear while adapting to evolving needs.

Ultimately, roadmaps create clarity and focus while showing teams how their work contributes to a bigger purpose. How do you structure your roadmaps? What has worked for you in balancing short-term wins with long-term goals? I invite you to share your strategies or challenges in the comments. Talk soon, take care.

To learn more:

Understanding the problem space in product management

Mariana Caldas — Fri, 20 Dec 2024 23:56:58 +0000

Ever heard the expression, “Don’t put the cart before the horse”? In product management, that’s exactly what happens when teams jump to solutions before truly understanding the problem. In this article of our product management series at Web Dev Path, we’re diving into the problem space—an essential concept for evaluating opportunities and ensuring products solve real customer needs.

Neglecting the problem space can lead to costly missteps, wasted resources, and products that fail to resonate with users. Understanding the problem space helps you uncover unmet needs, validate opportunities, and, especially, avoid the pitfalls of solution-first thinking. Let’s break it down!

What is the problem space?

The problem space is all about understanding your customer’s reality. It’s where you define the problem you’re solving without jumping ahead to potential solutions. This approach ensures you’re addressing a meaningful customer need, not just building something for the sake of it.

Contrast this with the solution space, which focuses on brainstorming how to solve a clearly defined problem. A clear distinction between these spaces prevents conflating ideas and builds a solid foundation for product success.

Problem space vs. solution space

Let’s consider we’re a dating app platform trying to understand our users' pain points:

Problem space: “I’m successful, but I don’t attract the person I like on dating apps and barely get matches.”
Solution space: “Let’s design a feature highlighting authentic personality traits in profiles.”

"By spending time in the problem space, you ensure that solutions are grounded in real user needs while they are feasible technically and will bring real value to the company."

Framework for understanding the problem space

To navigate the problem space effectively, product managers can use the following five-step framework:

1. Define success

Success starts with a measurable outcome. For example:

"Our product will be successful if we increase our users’ match quality by 50% within six months."

2. Choose your customer

Decide whether you’re targeting B2C or B2B customers and refine your target market. For example:

"Well-educated single professionals aged 30-50 seeking meaningful romantic connections."

3. Identify problems vs. opportunities

Understanding the difference between problems and opportunities is crucial:

Problem: An unmet need or desire (e.g., “I don’t know how to make my dating profile stand out.”)
Opportunity: A validated idea that benefits both the user and the company (e.g., “A personalized profile enhancement service that increases matches for users.”)

4. Market sizing

Assess the market potential to ensure your product can sustain itself:

Total Addressable Market (TAM): The global dating market in North America is valued at $9.5 billion in 2024.
Serviceable Addressable Market (SAM): Well-educated professionals in a determined region.
Target Market (TM): Single professionals aged 30-50 seeking personalized dating guidance.

"Think of TAM as the entire pie, SAM as the slice you could reasonably access with your resources, and TM as the specific bite you aim to take."

Another example

Let’s say you’re building a career coaching platform. The global market for career coaching services is estimated at $15 billion (TAM). Within that, you focus on professionals in North America, a $5 billion market (SAM). Finally, your target is mid-career tech professionals in metropolitan areas, narrowing it down to a $500 million opportunity (TM). This breakdown ensures you’re addressing a realistic and attainable audience while leaving room for growth.

5. Conduct user research

Effective user research is at the heart of understanding the problem space. Use a mix of qualitative and quantitative methods:

Qualitative analysis: Conduct 10-15 in-depth interviews to identify pain points.
Quantitative analysis: Use surveys to confirm findings on a larger scale.

Tips for customer interviews:

Start with easy questions to build rapport.
Dive into day-in-life questions to uncover pain points. That means understanding the users’ routine to ensure the solution fits their current habits.
Conclude with open-ended questions like: “Is there anything else you’d like to share?”
Avoid leading questions or trying to confirm your assumptions.

Why does the problem space matter?

Skipping the problem space often leads to solutions without substance. Here are three real-world examples of products that failed because they conflated solutions with problems:

Google Glass: Assumed people wanted wearable tech without solving an apparent problem.
Juicero: Overengineered a juicing solution for a non-existent pain point.

Products must also capture market value to sustain themselves. Consider Quibi, a short-form video platform. While it solved a real problem, its inability to monetize effectively led to failure.

On the other hand, successful products like Airbnb and Slack succeeded because they started with a clear problem and validated it through early testing.

"The problem space is the foundation of impactful products. By investing the time to understand your users and their challenges, you’re not just building solutions—you’re creating value."

Final thoughts

Staying in the problem space doesn’t just help you avoid wasted resources—it also fosters empathy, clarity, and alignment across teams. It’s the difference between building for your users and building for the sake of it.

What strategies do you use to stay in the problem space? I invite you to share your experiences or questions in the comments below. Talk soon, take care!

Understanding the product lifecycle

Mariana Caldas — Wed, 18 Dec 2024 06:51:54 +0000

As a product manager, your ultimate goal is to navigate ideas from inception to execution while delivering value to your customers and stakeholders. One of the core tools at your disposal is the product lifecycle framework, an essential structure for solving problems and guiding products to success. In this article, we’ll explore the six phases of the product lifecycle focused on a digital product (web or mobile) and discuss how they equip product managers with a scientific and adaptable approach.

What is the product lifecycle?

The product lifecycle is a framework designed to take an idea from start to finish. While it may seem like a step-by-step process, it’s important to understand that this lifecycle isn’t always linear. Instead, it’s a dynamic and iterative method, much like the scientific method, allowing teams to evaluate, hypothesize, experiment, and refine.

By providing structure, the product lifecycle helps teams answer critical questions:

What problem are we solving?
Why is it important?
Who are we solving it for?

It’s common to revisit earlier phases, like evaluating opportunities or designing solutions, based on insights gained from later stages, ensuring continuous improvement. These questions drive clarity and focus, ensuring that every phase is rooted in delivering meaningful outcomes.

The six phases of the product lifecycle

The Stanford Product Management Program presents those six product lifecycle phases with a different naming approach than the conventional approach, highlighting the importance of measuring and iterating aspects of that cycle, which I find quite convenient, especially for digital products. Let’s dive into them:

Evaluate the opportunity

Every great product begins with a well-defined problem. In this phase, product managers assess the opportunity by understanding the problem space and identifying why it matters. This involves diving deep into customer needs, gathering qualitative and quantitative data, and determining whether the problem aligns with the company’s strategic goals. Ultimately, this phase answers: “What problem are we solving, and who are we solving it for?”

How does that happen?

A product manager interviews potential users to uncover pain points in managing their daily tasks. Meanwhile, the UX researcher and data analyst collaborate to validate the findings using surveys and market analysis.

Tools: Google Trends and Typeform.

Design the solution

Once the opportunity is validated, the next step is to figure out how to solve it. This phase revolves around ideating and prototyping potential solutions, keeping customer feedback and usability in mind. Collaboration across design, engineering, and other stakeholders is crucial to creating a solution that balances feasibility, desirability, and viability.

How does that happen?

Designers create wireframes for a task management app while engineers provide feedback on technical feasibility. Product managers facilitate discussions to ensure the solution aligns with business objectives.

Tools: Figma, Adobe XD, and Maze.

Build

With a clear solution in mind, the team moves into execution. The build phase involves developing the product or feature while maintaining open communication between teams. Agile methodologies often shine here, enabling iterative progress and regular checkpoints to ensure alignment and quality.

How does that happen?

Front-end and back-end developers implement features like task scheduling and notifications. QA testers work alongside them to identify bugs early, ensuring a smooth development process.

Tools: Jira and CI/CD pipelines.

Ship (Launching time!)

This is the moment of truth—bringing your product to your customers. Whether it’s a soft launch, beta release, MVP, or full-scale deployment, the goal is to deliver value while closely monitoring performance and reception. Successful shipping also means clear internal coordination and external communication.

How does that happen?

The marketing team launches a campaign announcing the app's beta version. Customer support prepares for incoming queries, while the product team monitors analytics to track user engagement. Teams might first opt for a regional rollout or feature flagging to test specific functionalities with a smaller audience.

Measure

The product’s journey doesn’t end at launch. Measurement is critical to closing the feedback loop. Product managers can evaluate whether the solution effectively solves the problem and meets business objectives by collecting data on customer satisfaction, usage patterns, and other KPIs.

How does that happen?

A data analyst reviews app usage metrics, identifying trends in task completion rates. The product manager gathers qualitative feedback through user interviews to complement the data.

Tools: Google Analytics or Mixpanel and NPS surveys.

Iterate

Sometimes, the first attempt isn’t the final answer. Iteration involves using insights from the measurement phase to refine or reimagine the solution. This could mean minor adjustments or entirely revisiting earlier phases. Iteration is what keeps products evolving and improving over time.

How does that happen?

Based on feedback, the design team tweaks the app’s interface to improve usability. Developers implement the changes, and the QA team ensures the updates don’t introduce new issues.

Why the Product Lifecycle Matters

The product lifecycle framework is more than a checklist; it’s a mindset. By breaking down complex projects into manageable phases, product managers can:

Stay customer-focused: Each phase emphasizes understanding and meeting user needs.
Adapt effectively: Iteration ensures teams stay flexible and responsive to feedback.
Drive alignment: A shared framework fosters collaboration and clarity among cross-functional teams.

Adopting the product lifecycle also ensures that decisions at every stage align with broader business goals, like increasing customer retention or driving revenue growth.

Applying the product lifecycle to your work

Whether you’re leading a startup or managing features for an enterprise product, the product lifecycle offers a repeatable yet adaptable approach to problem-solving. By embedding this framework into your practice, you’ll be better equipped to navigate uncertainty, prioritize effectively, and deliver value for today and throughout your product’s entire journey.

What challenges have you faced in applying the product lifecycle? In the comments below, I'd love to learn from your experiences or questions. Talk soon, take care.

An introduction to product management

Mariana Caldas — Wed, 20 Nov 2024 02:45:22 +0000

In today’s fast-paced tech industry, product management plays an important role in turning innovative ideas into impactful solutions. This article is the first of a new series on product management brought to you by Web Dev Path. Over the coming months, we’ll explore the essential concepts, tools, and product management practices.

This series will draw on my experience as a head of product, scrum master, tech project manager, and front-end developer, along with insights from the Stanford Product Management Program. It will focus on examples and practices tailored to the IT field.

Whether you're new to product management or looking to refine your skills, this series will help you understand the core principles and apply them effectively in a tech context. Let’s get started with an introduction to the fundamentals of product management.

What is product management?

Product management is all about guiding a product from its initial idea through development and into users' hands. At Procter & Gamble (P&G), Neil McElroy first defined the role of a product manager in 1931. McElroy realized that marketing and development teams often struggled to align their efforts, so he proposed the concept of the “brand man” — a dedicated role to bridge this gap and ensure better collaboration.

Today, the product manager acts as the "CEO of the product," focusing on three core aspects or pillars:

User needs: What problems are users facing, and how can the product solve them?
Business objectives: How can the product align with the company’s goals, like increasing revenue or market share?
Technical feasibility: Can the product be built effectively within the given time, resources, and technology constraints?

Unlike project managers, who are primarily concerned with delivering projects on time and within budget, product managers prioritize features, long-term strategy, and the overall product vision.

Example

Let’s look at Instagram. When the product manager decided to launch the "Reels" feature, they did so based on growing user demand for short-form video content. This decision aligned with Instagram’s business goal of increasing user engagement and competing with TikTok.

While product managers are often seen as the "CEO of the product," they don’t have direct authority over development teams. Instead, they lead through vision, collaboration, and strategic influence.

More about the role of a product manager

Now that we’ve defined product management, let’s take a closer look at the responsibilities of product managers and their various roles.

Key responsibilities

The role of a product manager is multi-faceted and involves:

Understanding user needs: Conducting research, surveys, and interviews to grasp what users want.
Defining product goals: Setting clear, actionable goals that align with the company’s vision.
Collaborating with cross-functional teams: Working with design, engineering, marketing, and sales to bring the product to life.

Example: Consider the product manager for Google Maps. They might collaborate with engineers to decide whether to implement new features like real-time traffic updates based on data analysis and user feedback.

A product manager knows not every feature request can be implemented. The best product decisions often involve trade-offs and carefully balancing the three pillars: user needs, business objectives, and technical feasibility.

Types of product managers:

Internal product managers: Build tools for internal use within their company, focusing on improving workflows for other employees.
B2B product managers: Develop products for other businesses, often working closely with sales teams and client companies.
B2C product managers: Create products for the general public, requiring extensive user testing and creative problem-solving to meet consumer needs.

Product vs. Project Management

While both roles require strong organizational skills, they differ in focus:

Product managers aim to achieve specific business goals (e.g., increasing user engagement) and measure success by reaching these goals.
Project managers focus on completing projects within set timelines and budgets, ensuring all tasks are executed as planned.

The product lifecycle: the product manager roadmap by essence

The product lifecycle outlines a product's journey from its initial idea to its eventual retirement. Understanding these stages helps product managers make informed decisions and adapt their strategies along the way.

Stages of the product lifecycle:

Idea generation and planning: Identify opportunities, conduct research, and draft a roadmap.
Development and iteration: Based on user feedback, build the product and create an MVP (Minimum Viable Product) for testing.
Launch: Introduce the product to the market, often supported by a marketing campaign.
Growth: Scale the product by increasing user adoption and expanding features.
Maturity: Maximize profits and optimize the product through incremental improvements.
Decline: Decide whether to retire, update, or pivot the product in a new direction.

Example

Facebook is currently in the maturity stage, focusing on optimizing user experiences and exploring new features like Reels to maintain engagement.

Understanding the role with a mini case study: Airbnb’s product journey

What does great product management look like in action? Let’s explore how Airbnb grew from a small idea into a global platform by applying product management principles.

Airbnb began as a small idea to offer affordable alternatives to hotels during a busy conference in San Francisco. Today, it’s a global platform for home-sharing and unique experiences driven by strong product management.

Let’s integrate the above with the key topics we are covering in this article:

What is product management? Airbnb’s founders acted as the first product managers, identifying a gap in the market (expensive hotel stays) and testing their ideas with early users.
Role of the product manager: Airbnb’s product managers collaborate closely with design and engineering teams to implement user-friendly features like booking tools and user reviews.
Product lifecycle: Airbnb evolved from the idea stage (testing with friends) to growth (international expansion). Today, it is in the maturity stage, focusing on optimizing user experiences and launching new services like Airbnb Experiences.

I invite you to analyze Airbnb’s current lifecycle stage. What challenges might product managers face now? What new features or improvements could help the product continue to grow?

Key takeaways and next steps

Product management is about balancing user needs, business objectives, and technical feasibility.
The role of a product manager includes setting the product vision, guiding development, and making strategic decisions.
Understanding the product lifecycle helps product managers plan and adapt at each stage of development.

What’s next?

If you found this introduction helpful, stay tuned for our next topic, where we will explore crafting product strategies and achieving product-market fit. Talk soon, take care.