Forem: Web Dev Path

My Experience with Solana

Satoshi S. — Mon, 06 Apr 2026 16:51:14 +0000

Intro

I’ll start with an update on my current work.

Last November, I began working with JB Music Therapy to build a music wellness application. We recently completed a large user testing phase with over 250 participants, including music therapy students. Now, we’re migrating the web application to Flutter in preparation for releasing it on the Google Play Store and Apple App Store.

Since I don’t yet have production-level mobile development experience, I’ve been actively learning through a Udemy course while working on the migration. It’s been a challenging but rewarding process.

As a contract worker, I have a flexible schedule. To take advantage of that, I decided to apply to the MLH Fellowship again. I’ve participated in the program three times before, and each time I’ve gained valuable skills and experience.

This time, I was accepted into the Web3 track and assigned to work with the Solana Foundation team. In this post, I’ll share my experience working with Solana.

If you're interested in my previous experiences in the program, please check the posts below.

Project We Were Assigned To

Usually, MLH Fellowship participants contribute to the existing large-scale open-source projects under the guidance of core maintainers, but this time was a bit different. Our team was tasked with building a system to aggregate stablecoin metrics from multiple data providers and present them in a unified dashboard for the Solana Developer Website.

Why is this important? Because metrics can vary depending on the data provider. Differences in calculation methods, definitions, and data sources often lead to inconsistencies. Having a single place to visually compare these metrics makes it easier to understand and validate the data.

To support this, we are building a data pipeline on Databricks that pulls data from five major cryptocurrency analytics platforms: Allium, Artemis, Blockworks, DefiLlama, and Dune.

We are in the process of open-sourcing the data retrieval repository so that other developers can easily add new data providers or extend the available metrics in the future.

Explore the API

As a starting point, we decided to retrieve four core metrics.

metrics = [
  {
    'name': 'Supply',
    'unit': 'USD',
    'description': 'Total circulating supply of stablecoins on Solana, denominated in USD.'
  },
  {
    'name': 'Transfer Volume',
    'unit': 'USD',
    'description': 'Total transfer volume of stablecoins on Solana, denominated in USD.'
  },
  {
    'name': 'Transfer Count',
    'unit': 'Count',
    'description': 'Total number of stablecoin transfer transactions on Solana'
  },
  {
    'name': 'Active Addresses',
    'unit': 'Count',
    'description': 'Number of unique addresses interacting with stablecoins on Solana'
  }
]

We explored each API using notebooks to retrieve these metrics and understand their data structures.

During this process, we encountered several challenges, such as handling paginated responses, working with SQL-based APIs and adapting to different data schemas across providers.

Ingestion Pipeline

After exploring data provider APIs, we moved on to building the ingestion pipeline. We set up a database on Databricks and stored the data in a consistent format. During this process, we also began structuring the codebase with the goal of open-sourcing it in the future.

Dashboard

Databricks provides built-in dashboarding capabilities, which we used to visualize the aggregated data. I leveraged the AI Agent to generate plots quickly, allowing us to compare metrics across providers. Databricks also provides embeddable HTML components, which we plan to integrate into the final Solana developer page.

Repository Structure Proposal

We are now halfway through the Fellowship and have started organizing our code from Databricks into a structured GitHub repository.

solana-stablecoin-benchmark/
  providers/        # contributors add providers here
  normalizers/      # shared transformation logic
  pipelines/        # ingestion + normalization orchestration
  db/               # schema definitions
  config/           # config files (logging, env templates)
  tests/            # validation and correctness
  notebooks/        # optional exploration (Databricks / local analysis)
  main.py           # pipeline entry point
  requirements.txt  # dependencies
  .env.example      # API keys template
  README.md

This structure is designed to make the project easy to extend, allowing contributors to add new data providers and metrics with minimal friction.

Conclusion

Throughout the project, effective communication has been just as important as technical implementation. Since our team is distributed across multiple time zones, we rely heavily on asynchronous communication.

To support this, I've focused on clearly documenting my work so that teammates can easily understand progress and continue development without blockers. This experience has reinforced how important well-written documentation is for team productivity.

This project has been a great opportunity to deepen my experience in data engineering and collaborate in a distributed team environment.

Note

I plan to update this post at the end of the program with the final results of our work. I hope you can check it out on GitHub and the Solana website.

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.

Web Dev Path Updates - May 2025

Cheryl M — Thu, 22 May 2025 00:11:43 +0000

Expanding the team

Since 2020, Web Dev Path has been building a supportive, hands-on community where entry-level tech professionals grow through real experience. Now, we’re stepping into our next phase: onboarding web projects from Canadian small businesses and non-profits that are willing to fund development costs while supporting community learning.

In the last month, we have onboarded four scrum masters and project mangers. Now we are looking for two UI/UX designers to join our team! If you're interested, please send us a message on our website - www.webdevpath.co. Be sure to include your LinkedIn profile and a short introduction so we can schedule a meeting with you!

Migrating to Typescript

We have started planning to migrate our website from JavaScript to TypeScript. This will happen in stages:

1. Upgrade all packages

This includes upgrading Next.js to version 15, React to v19, and we will also have to upgrade Node.js version on Netlify.

2. Setup Typescript Support

Following the Typescript Migration Guide, we will set up the project in a way that it supports both TypeScript and JavaScript files during the transition phase. All new pages and components will be made with typescript while we gradually migrate old JavaScript files to TypeScript.

Moving Away from Styled components

We have completed the migration to styled-components on our website in 2023. Recently, styled-components announced that they are entering maintenance mode. We had a discussion as to whether we have to move away from styled-components.

We believe it might be something we eventually need to do, but there is no immediate need to move away from it. In the next few months, we will investigate alternatives to styled-components, and develop a strategy for the migration.

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 🚀

My Experience with OpenStack Ironic

Satoshi S. — Fri, 14 Mar 2025 17:56:14 +0000

Intro

I'm excited to share that I've been accepted into the MLH fellowship program for the third time. This time, I work on OpenStack/Ironic under the guidance of the G-Research Open Source Team.

If you are interested in my previous experiences in the program, please check the posts below.

What is OpenStack?

OpenStack is an open-source cloud computing platform that allows organizations to manage compute, storage, and networking resources. It provides an alternative to proprietary cloud platforms like AWS, Azure, and GCP, offering similar services while giving users full control over their infrastructure.

OpenStack follows a modular architecture, meaning it consists of multiple components, each responsible for different aspects of cloud management. One of these components is Ironic, which I'm working on in this fellowship.

For more details, visit the OpenStack website.

What is Ironic?

Ironic is an OpenStack component designed for managing bare metal infrastructure. It allows users to provision and manage physical servers in a way similar to virtual machines, providing greater flexibility and automation for hardware deployments.

My Works

Writing Hardware Manager Container-Based Cleaning (75%)
Fixing bugs and updating documenatation (20%)
Code Review (5%)

Writing Hardware Manager Container-Based Cleaning

My mentor assigned this as my main task for the internship. I feel fortunate to work on this feature, as G-Research (the program sponsor) has wanted it for a while. I’ve spent most of my time implementing it.

Ironic Python Agent is a key actor in Ironic, responsible for preparing machines for deployment. It runs on a ramdisk and performs cleaning, inspection, and provisioning actions by performing "steps" in a given order. As you can tell, I'm going to enhance the cleaning process.

I created this issue which was approved in the Ironic Team meeting. Currently updating Cleaning tools for Ironic nodes(servers) requires modifying and redistributing the entire IPA ramdisk image. With this new feature, users will only need to update their cleaning container image, significantly simplifying the process.

When I was first assigned my main task, I had no idea where to start. But after following my mentors' step-by-step guide, I gradually gained a clear understanding. Here are some of the steps I went through.

Step 1: Deploy Devstack on AWS VM

DevStack is a lightweight way to set up an OpenStack environment for development and testing.
Running it on an AWS VM provides a cloud-based environment to test Ironic and Ironic Python Agent.

OpenStack development happens on remote server, which I find really enjoyable. So far, I've broken my VM 3 times so far and had to start over from scratch each time.

Step 2: Add Custom Cleaning process to the IPA RAM

Confirm the autocleaning leave the log(Ex print("Cleaned by Satoshi"))

Step 3: Add Podman(Container) operations to the cleaning

Integrate container operation into the custom cleaning process using Podman

Step 4: Implement a config-driven approach

This allows users to set up container-based cleaning steps easily by modifying config files, without needing to change the project's code.

End Goal

I'm almost done with the feature implementation, but landing three PRs across different repositories is not easy.

Add ContainerHardwareManager (PR to ironic-python-agent)
Create Podman DIB (PR to ironic-python-agent-builder)
Send Container Configuration to IPA(upcoming PR to ironic)

The first two are waiting for reviews and I'm about to start working on the third PR. If I manage to land all three, I'll consider this a big success.

Some Issues I worked on so far

Besides the main task, I picked up some issues.

Documentation - Create Reference Page

This was my first PR to the OpenStack/Ironic. I learned how to use development tools (Gerrit, Launchpad) and how to write commit messages for OpenStack.

I am glad I impressed my mentor with this PR.😄

Code - Code Refactoring and Log enhancement

While this wasn’t technically challenging, I’m really proud of this work because it will help future developers. During development, I initially missed making the kernel/ram image public, and the log simply stated that the image wasn’t found.

In this log enhancement, I made it much easier to spot the actual issue: a permission problem. It took me quite a bit of time to fix, but it was worth it to improve the debugging process for anyone working with the code in the future.

Conclusion

I'm grateful for this great learning opportunity provided by MLH fellowship and G-Research. A lot of learning has happened in this short amount of time. I will be implementing a feature that many companies will rely on sooner.

Happy coding!!

After Notes

I successfully wrapped up my internship with OpenStack/Ironic. You can check my contributions here. I created 15 PRs, including container-based cleaning features, and reviewed 5 PRs during the program.

It's been an incredible learning experience. I hope this journey opens doors to new opportunities.

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.

Start contributing to a Popular Open Source Project

Satoshi S. — Tue, 28 Jan 2025 19:33:49 +0000

Prelude

Taipy is a Python web framework for data-driven applications. Developers can build web applications only with Python. The simple method for building web applications is especially beneficial for Data Scientists and analytics professionals. They are gaining popularity in the field. At the time of writing this post, they have 1.9k forks and 17.6k stars.

I have been contributing to Taipy for a while now. I started because of my strong interest in data science and analytics, and I felt that my tech skills aligned well with the project. Contributing has given me practical experience solving problems for developers using this framework, and I’ve learned a lot from feedback provided by experienced maintainers. During Hacktoberfest, I found many developers struggled to test their updates on their environment. I want to share my workflow in this post. I hope this helps someone who wants to contribute to Taipy.

Setup the workflow

When you want to start contributing to a project, you will go to the CONTRIBUTING.md first. Once you read through the contribution guide. You will find Taipy is using React behind the scenes even though users don't need to touch any JavaScript.

The majority of my contributions are for the React part. To check updates, you need to build the React, install the updated Taipy to your Python environment, and run a test Tapy script. It's a bit of work to do this every time. I created a bash script for this.

taipy-build.sh

#!/bin/bash
# automate build process of Taipy repo

# Build taipy-gui
cd ~/projects/taipy/frontend/taipy-gui/dom;
npm i;
cd ..;
npm i --omit=optional;
npm run build;

# Build taipy
cd ~/projects/taipy/frontend/taipy;
npm i;
npm run build;

# install new taipy

cd ~/projects/test-taipy;
source venv/bin/activate
pip install ../taipy

After running this script, I just run taipy run --use-reloader main.py in the virtual environment. You can see the updated behavior.

pip install ../taipy is important you install taipy locally. Please point to the taipy in your file system.

Example PR

Let's take a look at my first PR to Taipy in 2025.

A developer found the height property is not working on the Selector component in Radio mode.

The first thing to do is to create a simple Python script to reproduce the bug. Otherwise, we cannot check if the update fixed the issue. In this issue, the maintainer provided a script, so I used his script.

Once I reproduced the bug, I started looking at the Taipy codebase. While searching "Selector", I found the file to work on for this issue "Selector.tsx". I also found the height property is not used for radio mode and check mode in the selector component. I need to pass the height property somehow. Following other styling property handling, it's better to use useMemo and create heights.

Initially, I passed the Sx to the parent element(FormControl), it worked fine as expected but the maintainer gave me feedback that it's better to control styling from RadioGroup/FormGroup level as the label remains visible on the Taipy app. This gave me a challenge because the styling didn't work as expected in this way.

While playing with the styling on the browser developer tools, I found that flexFlow: column wrap was the reason for this behavior. I added flexFlow: 'column nowrap to the heightSx. I validated this work as expected with the test script after installing the updated taipy.

After implementing it, I need to create unit tests. Adding a new test case is not so bad as I can see many examples from the existing tests. I added new tests for radio and check mode height styling.

It looks straightforward but it took me lots of tries and errors. After refining a PR with the maintainers' feedback, it's getting approved and merged.🎉🎉

Pick the right issue for you

I know the feeling that you want to do impressive work, however, it's not sustainable for you and the maintainers if you take too difficult issues for your level. Easier issues will get you familiar with the project and you also learn something new. I usually research the issue a bit before asking for the assignment to ensure I can handle it.

As Tomo Fujita says

Don't Worry
Don't Compare
Don't expect too fast
Be kind to yourself

If contributing to Taipy repo is too much, you can also take a look at taipy-doc. Documentation matters for libraries.

Conclusion

Contributing to Taipy has been a rewarding journey. Whether you’re fixing bugs, enhancing features, or improving documentation, every contribution matters. Don’t hesitate to start small—your efforts could help the next developer struggling with the same issue!

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.