I have found and continue to find much joy in the IC PM role versus the alternative management route.
Wholeheartedly agree that PMs should take the time to figure out what's right for them, and advance their careers accordingly 👌
Founders, what’s helped you navigate tech discussions? Let’s share tips. 👇
#Startups #ProductManagement #NonTechnicalFounders #Leadership #SoftwareDevelopment
goodproductmanagement.com/the-non-tech...
💡 Bottom line:
You don’t need to write code to lead a great product.
You do need to communicate clearly, ask good questions, and align with your dev team.
Tech is just another language—learn the basics, and you’ll be fluent in no time. 🚀
✅ Focus on business outcomes, not tech solutions.
😭 Bad: “Can we add a caching layer to this API?”
👍 Good: “Our response times are slow—what’s the simplest way to speed them up?”
Your job is to define the problem, not dictate the solution.
✅ Play with no-code tools to build intuition.
Platforms like Zapier, Webflow, or Retool let you experiment with software concepts without coding.
The more you tinker, the more things start making sense.
✅ Learn to skim (not write) technical docs.
You don’t need to code, but you do need to extract key insights from API docs, error logs, or system diagrams.
A little effort here will massively improve your dev discussions.
✅ Ask the right questions.
You don’t need to sound smart—you need clarity. Try:
- “What’s the simplest version of this feature we could launch first?”
- “What are the biggest risks here?”
- “If we doubled our users overnight, what would break first?”
✅ Use analogies to make tech click.
Complicated topics? Make them relatable:
- APIs → Like a waiter taking your order to the kitchen.
- Load balancing → Adding more lanes to a highway.
- Caching → Bookmarking a page instead of searching every time.
✅ Build a mental model, not just a vocabulary.
Don’t just memorize jargon—understand how things fit together:
- Frontend vs. Backend (UI vs. engine)
- Databases (storing & retrieving data)
- APIs (systems talking to each other)
- Infrastructure (where everything runs)
First things first: You don’t need to know everything.
But if you can’t communicate with your developers, your product (and business) will suffer. Here’s how to bridge the gap:
founder describes problem for dev team to solve
💡 Non-technical founders: You don’t need to write code, but you do need to speak tech.
Building a product without a technical background can feel like learning a new language. Here’s how to navigate tech discussions without getting lost. 🧵👇
12/ Use these checklists & heuristics to stay focused.
And if you need help defining quality for your product—reach out! 🔥
Read the full article (all the points above and more) here: goodproductmanagement.com/product-qual...
11/ Final takeaway:
Voltaire said: Perfect is the enemy of good.
Your job isn’t to build a perfect product—it’s to build something valuable & reliable enough that people will pay for it and keep using it.
10/ Measure what matters
* Is anything blocking revenue?
* Are users leaving because of quality issues?
* Are you staying ahead of security & performance risks?
9/ What quality issues actually matter?
You’re a founder, not a perfectionist. Focus on:
🔹 Value delivery
🔹 Keeping the business running
🔹 Scaling without breaking
8/ Different lenses for different discussions:
* UX: "Where might users get stuck?"
* Business: "Will this help us scale?"
* DevOps: "What happens if 100x users show up?"
7/ Talking to Developers Without Sounding Clueless
Forget "sounding smart." Ask great questions instead:
🛠 "What’s the worst thing that could happen here?"
👥 "How will a first-time user experience this?"
📈 "What metrics will show if this is working?"
6/ Other useful tools:
✅ Feature Readiness Checklist – does it meet minimum quality?
✅ Quality Debt Tracker – track risks & prioritise fixes.
✅ Release Quality Verification – test before launch.
✅ Quality Metrics Dashboard – track trends over time.
5/ A simple way to assess quality 👇
Use a Quick Quality Scan (10-minute test):
1️⃣ Reliability (1-5)
2️⃣ Error frequency (1-5)
3️⃣ Speed (1-5)
4️⃣ Data accuracy (1-5)
5️⃣ UI clarity (1-5)
Total /25. If <20, fix it.
4/ Instead of chasing perfection, think in terms of qualities:
🎯 Usability – is it a pleasure to use?
🔒 Security – is it protected from bad actors?
⚡ Performance – does it run fast enough?
🔧 Maintainability – how easy is it to fix & update?
3/ Quality risks differ depending on:
* Your audience
* The product type & business model
* How it’s built & delivered
* Legal & regulatory constraints
* Product maturity & constraints
2/ A simple definition:
"Quality is value to some person." - Jerry Weinberg.
Your job is to define:
✅ What value your product delivers
✅ What risks threaten that value
1/ What is quality, really?
You know it when you see it, but defining it? Tricky.
Robert Pirsig (Zen & the Art of Motorcycle Maintenance) spent two books philosophising about it, but we need something practical.
Every non-technical founder has been here: Your developer says something will take 3 weeks instead of 3 days, and it sounds like a foreign language.
Are you being taken for a ride, or is it really necessary?
Let’s break it down. 🧵👇
Livestreaming in ~8hrs, our top 10 insights from the inaugural Testmo user survey. Join us for live polls and discussion with the @testmoapp.bsky.social team. I'll also be sharing a preview of what's currently and soon to be in development!
#SoftwareTesting #Quality #TestManagement #TestAutomation
Wins, fumbles, lessons—it’s all part of the process. Reflecting on my week helps me uncover what’s working, what isn’t, and where to go next.
What did your week teach you?
5. Building a bridge to ambition
Juggling content creation feels daunting, but small steps win the race. Focus on cornerstone content, strategic experiments, and growth. The leap doesn’t have to happen all at once—it’s about intentional progress: goodproductmanagement.com/processes/ag...
4. Writing is therapy
Drafting blogposts and guides helped me untangle thoughts this week. Writing is work, but it’s also a refuge. Sharing those thoughts? That’s where feedback sparks new ideas and better paths forward. Write, share, learn, repeat.
3. The sleep struggle is real
Coming back from vacation is like starting a marathon mid-sprint. Two micro-naps later, I faced reality: bad sleep routines aren’t fixed through self medicating with a couple of glasses of wine... Note to self: ditch the quick fixes, prioritise real rest.
2. Feedback can be a win
My GM told me I’ve “got things well in hand” and plans to step back from some meetings. Why’s that a win? It’s feedback I pushed for during year-end reflections. Seeing your ideas take root = satisfying. Speak up—it might just pay off.
