More cases

Product Story see my decisions

Each case here covers a single decision: the context, what I did, the result and what I learned.

01 · Retail · sales app

An app in 1 month for people who had lost trust

I took over the salespeople's app at a fashion retailer after the web version failed, and delivered a new app in 1 month. Within 3 months it was in all 52 company-owned stores, and adoption went from 60% to 92%.

Context: Salespeople talk to customers on WhatsApp. The web version that replaced the old app opened an extra page before WhatsApp, was slow and made people lose links and passwords. The product wasn't mine: I worked close to the team because the two apps shared microservices, and I had recommended a native app from the start.
What I did: I raised the problem again and offered to deliver a minimal version in 1 month. My job was deciding what stayed out. We reused most of the API, and I limited version 1 to three areas: the main flow (customers, campaigns and goals), authentication, which was the biggest pain, and customer distribution, which depended on a slow vendor API, where I ran the tests together with the vendor's team.
Result: We launched on time, with top satisfaction scores in the first month. We started in São Paulo and, within 3 months, were in all 52 company-owned stores. Adoption went from 60% to 92%.
What I learned: The web version failed on everyday friction: an extra page, slowness, lost passwords. Today, when I take over a rejected product, v1 goes only after what blocks the daily routine and stays on a few fronts; the rest waits for trust to come back.

02 · E-commerce · data

The funnel nobody had

When the company's own app went live, nobody knew where customers dropped off. I built the funnel from scratch, and it guided the decisions that took conversion from under 1% to 5%.

Context: With the app live, there was no funnel structure: only active users, clicks, number of purchases and revenue. And events weren't mapped correctly, so the numbers weren't reliable.
What I did: I took over the data front, which had no owner. I mapped the events with engineering, structured the funnel, defined the metrics and built the customer dashboard with the data team.
Result: The funnel became the basis for the decisions that followed: the rebuild of the collection page and the PDP, the home test and the new checkout. By the end of that program, conversion had gone from under 1% to 5%.
What I learned: Before trusting a number, I check the event: does it fire once, on the right trigger, on both platforms? Does it match another source? What changed recently?

03 · E-commerce · experimentation

The inconclusive test that became a win

An A/B test on the home page was inconclusive and pointed against the variant. Instead of closing it, I raised hypotheses, we iterated, and the variant ended up winning.

Context: I planned and followed the home page A/B test, control against variant, from February to May. Purchase was the primary metric and add to cart the secondary, with iOS and Android read separately.
What I did: In the first cycle, the variant lost on both platforms, but without significance. Instead of ending the test or launching on taste, I located where the loss happened: in the middle of the funnel. I raised hypotheses about content hierarchy and CTA clarity and specified a new version, with clearer value and a more visible CTA.
Result: The hypotheses held: the new version turned it around, and the variant won.
What I learned: In the first cycle the loss sat in the middle of the funnel, not across the whole home page. Today, before closing an inconclusive test, I find the step where the variant loses and write the next hypothesis for that step.

04 · E-commerce · generative AI

AI virtual try-on, validated in stages

I defined how to validate an AI virtual try-on before putting it in front of customers. We launched in 2 stages, and it was the public opening that showed cases no internal test had caught.

Context: The brand wanted a virtual try-on with generative AI. A bad image in front of a customer would hurt the brand, so quality was the biggest risk. Engineering built the feature; the product decisions were mine.
What I did: I defined the metrics, guardrails and success criteria for the images and ran tests with many types of images. I designed the rollout in 2 stages: internal first (employees, family and friends), then customers, only on specific collections.
Result: Internal tests caught a lot, but only the public opening showed scenarios nobody had imagined. The feature went to production and engagement with the app went up.
What I learned: The internal beta caught a lot, but only real customers surfaced the cases no one had imagined. Today every generative AI feature ships with guardrails set in advance and goes through a small group of real users before general release.

05 · Platform · technical decision

CMS: migrate now or not

When Contentful cut the free plan we were using, the team wanted to migrate to Strapi. I ran a cost and scale study and proposed staying longer on Contentful, keeping engineering focused on the product.

Context: To manage content for one of the products, we chose Contentful because it was faster to integrate and the free plan covered the estimated demand. After implementation, Contentful limited several features of the free plan, and the team started considering a migration to Strapi, which is open source.
What I did: I ran a study of cost and of how our usage would scale on Contentful over time, compared it with the effort of migrating and took the proposal to engineering.
Result: We stayed longer on Contentful, with the migration planned for when the numbers justified it. Engineering time stayed on the product.
What I learned: Staying on Contentful had a predictable cost; migrating took engineering time away from the product. Today I bring engineering the projected cost over time and the number that triggers the migration, so the switch happens when the number says so.

06 · B2B SaaS · discovery

Stopping instead of defending the work

Discovery confirmed the problem, but showed our product wasn't the right answer. The direction had been mine, and I still argued for stopping. We rebuilt the product in 6 weeks.

Context: A B2B SaaS Customer Revenue Intelligence platform. The direction of the first product structure was mine. We built a working prototype and I ran more than 10 discovery sessions with potential customers.
What I did: Customers confirmed the problem, but saw the solution as something they already did or could build, and got lost in a menu of 12 options. I separated the evidence about the problem from the evidence about the solution, cut the navigation from 12 areas to 5 flows and replaced the initial dashboard with a "Today" screen, which shows what to do now and which actions generate revenue. I also built the prototype and the front-end.
Result: We rebuilt the product in 6 weeks, and it is now with companies in the beta phase.
What I learned: Customers confirmed the problem and still got lost in a 12-item menu. Today I separate evidence about the problem from evidence about the solution, and test whether users know what to do on the first screen before treating demand as a signal to scale.

07 · Pet care · pricing

A price customers could understand before booking

The price of each service depended on the pet's weight and several other variables. I turned that into a clear amount in the app, before booking, and that is what made it possible to take booking out of manual service.

Context: The price of each service depended on many variables at once and changed with the pet's weight. It was the biggest challenge of the product: the app would only take booking out of manual service if customers could see how much they would pay.
What I did: I designed the pricing to turn all those variables into a clear amount inside the app, before booking, and treated price transparency as part of the conversion funnel.
Result: With the price visible in the app, booking no longer depended on support, and digital orders went from 20% (website) to 80% (app) in the first month.
What I learned: Booking only left WhatsApp once customers could see the price before booking. Today I treat the pricing rule as a funnel step and test that it is understood before designing the rest of the flow.