Design Community: Ulad Shauchenka

When UX Feels Broken, Troubleshooting as a Product Manager

Ulad Shauchenka — Sat, 27 Sep 2025 10:15:10 +0000

If product managers are plumbers 🪠, then designers are often the water engineers: you shape the flow, PMs patch the leaks. But here’s the thing—sometimes what looks like a “technical bug” is really a UX bug.

A confusing button label, a layout that hides a key action, or a flow that “works” technically but doesn’t work in the user’s head… all of those create the same effect: users feel like the product is broken.

Troubleshooting isn’t just an engineering task. It’s where PMs and designers meet in the messy middle—figuring out whether the pain is in the code, the flow, or the expectation gap.

Here are 5 ways I’ve found design + PM teams can troubleshoot together:

Treat UX confusion like any other incident

If users are “misclicking” or “getting lost,” log it. Write a ticket. Reproduce it. Treat usability breakdowns with the same seriousness as crashes.

Use customer signals as early warning

Support tickets, app store reviews, or tweets that say “this app sucks” aren’t noise—they’re the earliest signs of friction. Instead of shrugging, translate them into testable hypotheses: what’s the user expecting here?

Quick, scrappy usability tests > polished mockups

Polished Figma files can be comforting, but they won’t reveal where users stumble. Five scrappy tests on a prototype (or even a live product) often surface more “aha” insights than weeks of pixel-perfect design.

Don’t stop at “user error”

If 10 people misuse a feature, it’s not user error—it’s a design bug. Map out where users go off track. Segment by flow, version, or context. Most “weird behavior” becomes obvious once you zoom in.

Close the loop with the user

Fixes aren’t finished when the PR merges. Announce changes, show how you tested, and follow up on feedback. “We heard you, we fixed it” builds trust—and turns frustrated users into advocates.

Why This Matters

In product teams, PMs often chase stability while designers chase usability. But in reality, both break in similar ways: unexpected changes, confusing signals, unclear definitions of “done.”

When PMs and designers treat troubleshooting as a shared craft—not just a firefight—we uncover root causes faster, avoid shallow fixes, and design products that feel resilient instead of fragile.

Try this: Next time your team runs a postmortem, invite design. Ask: was this really a technical failure, or did UX play a role? You’ll be surprised how often the answer is both.

The Art of Troubleshooting as a Product Manager 11 steps to fix what’s broken (without losing your mind)

Ulad Shauchenka — Sat, 27 Sep 2025 10:14:48 +0000

If product management had a spirit animal, it wouldn’t be a lion or an eagle. It’d be… a plumber.

Why? Because half the time, you don’t know where the leak is, you didn’t cause it (probably), and someone’s yelling that the water’s cold.

Troubleshooting isn’t a “side quest” for PMs — it is the job. And when things break, your team looks to you to cut through the noise, steady the ship, and get users back on track.

The good news? Troubleshooting isn’t magic — it’s a repeatable skill. Here’s my field-tested playbook of 11 habits every PM can use to go from “ugh” to “aha!”

Be a scientist, not a hero

Your brain loves the first plausible explanation. Resist it. Write down your hypotheses, test them, and let the evidence guide you.

Define “broken” before it breaks

Set up SLIs, SLOs, and error budgets with engineering. If you can’t measure pain, you can’t fix it.

Instrument early, argue later
Logs, traces, metrics. If you don’t have them, you’re blindfolded. Build dashboards before things go sideways.
Listen to customers (but filter the noise)

Support tickets and reviews are gold… but also messy. Treat them as signals, not scripture.

Track the Four Keys

Deployment Frequency, Lead Time, Change Failure Rate, Time to Restore. If CFR goes up and TTR drags, you don’t have a roadmap problem — you have a stability problem.

Reproduce → isolate → segment

Who’s affected? What changed? Can you reproduce it? Ninety percent of mysteries solve themselves once you slice thin enough.

Find root causes, not scapegoats

Use Five Whys. Stop when you hit something actionable. And keep postmortems blameless — systems fail, not people.

Contain damage fast

Feature flags, rollbacks, canaries, guardrails — your first move is to shrink blast radius, not write a 50-page fix plan.

Watch out for “experiment emergencies”

Half of today’s “bugs” are messy A/B tests. Guardrail metrics and discipline stop experiments from wrecking your product.

Don’t ignore UX bugs

Sometimes “the app is broken” really means “the flow is confusing.” A few quick usability tests catch problems no log will.

Close the loop

A bug isn’t fixed when the PR merges — it’s fixed when users stop feeling it. Monitor, announce, and verify.

Why This Matters

Troubleshooting makes or breaks trust. Done right, it turns chaos into clarity and makes you the calm in the storm. Done wrong, it spirals into finger-pointing, lost users, and midnight deploys.

Being a PM isn’t about being the hero with all the answers. It’s about being the curious scientist who shrinks uncertainty — and the facilitator who helps the team learn faster next time.

11 Principles That Help Me Decide When to Research vs. Just Ship

Ulad Shauchenka — Fri, 26 Sep 2025 05:43:18 +0000

The other day, I watched a debate in my team about… a list.

Yep, a simple list of items. Half the team wanted to run another round of research. The other half said, “It’s a list, can we just ship it already?”

And it hit me: we often turn UX into an all-or-nothing game. Either we over-research the basics, or we skip fundamentals in the name of speed. Both extremes slow us down.

Here’s what’s helped me find middle ground:

ISO’s usability definition is a great compass: effectiveness, efficiency, satisfaction in context. If your design nails those three, you probably don’t need weeks of testing before launch.

Nielsen’s heuristics cover 80% of issues upfront. Checking for consistency or error prevention is often faster (and more useful) than another survey.

Iterate quickly, but anchor to principles. That way you avoid “analysis paralysis” and “move fast and break everything” chaos.

AI adds another twist — it can generate wireframes in seconds. But it still can’t tell you whether your design actually works for a technician in the field, or a customer under stress. That’s still on us as designers.

I wrote a longer piece on this (link below), but I’d love to hear from you:
👉 When do you say “this is good enough, let’s ship” vs. “nope, we need more research”?

Full article here: 11 Software Development Principles

Are We Overcomplicating UX? Why “Just Ship It” vs. “Research Everything” Is the Wrong Debate

Ulad Shauchenka — Fri, 26 Sep 2025 05:40:17 +0000

The other day, I watched a debate in my team about… a list.

Yep, a simple list of items. Half the team wanted to run another round of research. The other half said, “It’s a list, can we just ship it already?”

And it hit me: we often turn UX into an all-or-nothing game. Either we over-research the basics, or we skip fundamentals in the name of speed. Both extremes slow us down.

Here’s what’s helped me find middle ground:

ISO’s usability definition is a great compass: effectiveness, efficiency, satisfaction in context. If your design nails those three, you probably don’t need weeks of testing before launch.

Nielsen’s heuristics cover 80% of issues upfront. Checking for consistency or error prevention is often faster (and more useful) than another survey.

Iterate quickly, but anchor to principles. That way you avoid “analysis paralysis” and “move fast and break everything” chaos.

I wrote a longer piece on this (link below), but I’d love to hear from you:
👉 When do you say “this is good enough, let’s ship” vs. “nope, we need more research”?

Full article here: 11 Software Development Principles

7 Software Principles Every Product Manager Should Know (to Save Engineers From Headaches)

Ulad Shauchenka — Thu, 25 Sep 2025 05:27:18 +0000

As a PM, I’ve learned the hard way that launches rarely get blocked by “big unknowns.” More often, it’s the small technical mismatches Or repeated logic, over-engineered features, or a quick hack.

That’s why I started digging into core software engineering principles. Not to write code myself, but to speak the same language as my engineers and spot problems before they slow us down.

Here are 7 principles (in plain English) that every PM should have in their toolkit:

DRY — Don’t Repeat Yourself

Copy-pasted logic = triple risk. Push for reusable components so fixes happen once.

KISS — Keep It Simple, Stupid

Complexity is expensive. The simplest approach usually scales the best.

YAGNI — You Ain’t Gonna Need It

Don’t clog the roadmap with “future-maybe” features. Build for today’s needs.

Technical Debt = Real Money

Every shortcut is a loan with interest. Budget time for clean-up, or velocity drops later.

APIs & Microservices

Know your system boundaries. Clean contracts between services prevent nasty surprises.

Safe Release Practices

Deploy ≠ release. Feature flags and trunk-based dev give you flexibility when things get messy.

Simplicity Scales

At every level — code, scope, systems, process — simplicity wins.

Why This Matters for Product Managers

Understanding these principles changes the way you plan, write tickets, and negotiate trade-offs. It’s not about coding — it’s about making sure your engineers aren’t slowed down by decisions made upstream.

Stop Losing Launches to “Tiny Bugs”: 7 Engineering Principles Every PM Should Know

Ulad Shauchenka — Thu, 25 Sep 2025 05:00:57 +0000

Stop Losing Launches to “Tiny Bugs”: 7 Engineering Principles Every PM Should Know

Two weeks before launch, everything looked green — until a “tiny” change in a shared component broke checkout. Three teams owned three slightly different versions of the same logic. Fixing it took days.

Sound familiar? That’s not really a “bug.” That’s a requirements mismatch and it’s the kind of fire drill product managers can prevent if they understand how engineers think.

You don’t need to code. But you do need to speak the language of software development well enough to spot risk, ask sharper questions, and make trade-offs with your tech lead.

Here are 7 engineering principles, in plain English, that can save your roadmap (and your sanity):

DRY — Don’t Repeat Yourself

Every duplicated rule = triple the risk. One change should happen in one place. Push for reusable components instead of copy-paste solutions.

KISS — Keep It Simple, Stupid

Complexity is a tax. Fewer branches, fewer edge cases, fewer headaches. Always ask: what’s the simplest way to deliver this outcome?

YAGNI — You Ain’t Gonna Need It

Building for “what if” clogs your backlog. Ship what users need today, not what they might need someday.

Technical Debt Is Real Money

Shortcuts are loans with interest. If you don’t budget time for refactoring, that “quick hack” will slow you down next quarter.

APIs & Microservices

Know your system boundaries. Clean APIs = fewer surprises, faster parallel work, and easier partnerships.

Version Control & Safe Release Practices

Shipping ≠ launching. Learn the basics of Git, feature flags, and trunk-based development so you can separate deploy from release.

Simplicity Scales

At every level — code, scope, system, release — simplicity wins. That’s what keeps teams moving fast without breaking things.

Why This Matters for PMs

If you can talk about DRY, KISS, debt, and release strategies in planning, you stop being “the ticket writer” and start being a real partner to engineering. That’s how you prevent “tiny bugs” from derailing launches.

Pro tip: Grab 20 minutes with your tech lead this week and ask: Which of these principles, if we applied it more consistently, would speed us up the most? Then make it part of your next planning cycle.

If you want the full version of this write-up (with concrete examples, quotes, and references), I published it here: 7 Software Development Principles Every Product Manager Must Know

My First Month With a PS5 After Years on PC

Ulad Shauchenka — Wed, 24 Sep 2025 10:28:14 +0000

I’ve been a PC gamer forever. Valorant, CS, all-nighters on Discord that was my life. I always thought consoles were “watered-down PCs.”

Then I grabbed a PS5. And… wow. Totally different vibe.

Setup was a dream. On PC, I’d always run into controller disconnects, popups, or random updates. With PS5 it’s literally: power on → pick a game → play. Zero hassle.

The DualSense blew me away. I didn’t think a controller could matter this much, but the haptics and adaptive triggers in God of War actually made me feel the game.

Story games just hit different on the couch. I used to grind shooters for hours, but sitting back with Ghost of Tsushima or Spider-Man 2 made me realize not every game has to be about sweating for wins. Sometimes you just want to sink into a world.

Do I still love PC? Absolutely. Mods, performance, precision can’t beat it. But the PS5 reminded me that sometimes less tinkering = more fun.

👉 Anyone else switch over (even part-time)? What game made it “click” for you?

What are some of the biggest product failures of the last decade?

Ulad Shauchenka — Wed, 24 Sep 2025 09:29:29 +0000

There have been a lot, but a few stand out to me:

• Samsung Galaxy Note 7 (2016) – great device on paper, but two separate battery defects led to explosions, recalls, and a permanent discontinuation. A classic case of speed beating safety.

• Juicero (2017) – a $400 Wi-Fi juicer that turned out to be unnecessary when people realized you could squeeze the packs by hand. Proof that not every “innovative” product solves a real problem.

• CNN+ (2022) – shut down just 30 days after launch, despite $300M+ invested. A lesson in overestimating demand for “yet another subscription.”

I actually put together a list of 10 of the most notable product debacles from 2015–2024 with numbers, quotes, and takeaways.

Curious: which product flop do you think deserves the #1 spot?

What Minecraft & Roblox Got Right (And What Other Games Can Learn)

Ulad Shauchenka — Tue, 23 Sep 2025 05:18:18 +0000

So I’ve been thinking about why Minecraft and Roblox have managed to stay massive for so long, especially with Gen Z, and I feel like it comes down to a few simple things.

First, they don’t force you into a path. It’s not “beat boss → unlock gear → repeat.” It’s “here’s a world, do something fun.” That freedom means you can put in 20 hours or 2,000 and still find new stuff to do.

Second, they nailed first-session joy. You jump in, break a block, build something goofy, and you’re instantly having fun. Compare that to games that spend an hour making you grind through tutorials.

And then there’s the community/creator side — mods, servers, skins, UGC in Roblox, etc. When players are creating, the game never really runs out of content. Plus, cross-platform and social play keep things alive with friends.

I wrote a bit more about this on my blog, but here’s my big question for you all:
Do you think more games should lean into this kind of “player agency,” or do you prefer the structure of a traditional RPG/progression game?

Curious to hear what everyone thinks.

Minecraft addiction

Ulad Shauchenka — Tue, 23 Sep 2025 05:11:30 +0000

What I Learned from Netflix’s Data-Driven Product Strategy? and How You Can Apply It

Ulad Shauchenka — Mon, 22 Sep 2025 08:07:45 +0000

Hey everyone,

I recently wrote a case study on Netflix’s Data-Driven Product Strategy, and wanted to share a few lessons that turned out to be surprisingly useful, whether you’re on a big team or working solo.
What Netflix did

They identified small “friction” moments (for example, the delay before a show intro plays) and ran controlled experiments to test simple solutions like “Skip Intro.” That change is now used millions of times a day, and it improves session continuation.
They also personalized the artwork (tiles for shows/movies) to better match users’ tastes then tested what visuals led to more clicks and plays. What I took away (and use myself):
Always define a clear OEC (Overall Evaluation Criterion) and guardrails up front. Know what metric really matters.
Run experiments even for “small stuff.” Sometimes low effort ideas have big returns.
Use “platform thinking” make templates, metrics, dashboards that can scale. Don’t reinvent from scratch every time.
Combine quantitative data with real user feedback (screens, sessions, interviews) so you understand why something works or not. What this means for you:
Even if you don’t have Netflix’s user base, you can still apply experiments on small features.
Prioritize experiments based on exposure + cost.
Build a habit of measuring & reviewing experiment logs, small test groups, clear decision points.

Curious: for those here doing experiments
What metric (or “OEC”) surprised you most? What was an experiment that failed but taught you more than the successful ones?

From Start-up Essays to AI Side Projects: My Intro + Journey So Far

Ulad Shauchenka — Sun, 21 Sep 2025 07:22:31 +0000

Hey folks I’m Ulad.

Bit of background on me: I’ve been writing for a while about startups, product growth, and how tech can actually help people instead of just chasing the next shiny thing. One of my favourite pieces I put together was “The Path from Startup Innovation to Community Transformation” — it’s basically about building stuff with people, not just for them.

Lately though, I’ve been having a lot of fun experimenting with AI side projects. Nothing fancy — just seeing how far these tools can take you when you want to spin up digital products without a huge budget or a big team. Things like:

Drafting ebooks with ChatGPT, then cleaning them up and publishing on KDP

Journals, planners, and colouring books using AI-generated designs (Etsy’s been a solid test bed)

Stock art and merch designs with Midjourney

Even dabbling in AI-assisted courses

It’s not “set it and forget it” there’s still a chunk of upfront workbut once you’ve built the thing, it can keep ticking along with very little maintenance. That part feels pretty great.

Why I’m here: I’m hoping to swap notes with folks doing similar stuff. What works, what flops, what’s worth putting real energy into. Always open to learning new tricks, eh.

Anyway, that’s me in a nutshell. Excited to join in here.

Cheers,
Ulad