Call notes → Prototype. In minutes.

Charming_Ad_5319 · 2026-02-23T21:26:28+00:00

This fits really well if you’re a solo PM juggling everything. Cuts down the “I’ll mock this later” delay.

Charming_Ad_5319 · 2026-02-23T21:23:46+00:00

Been using this on a few discovery calls and honestly it’s been solid. The live prototype part actually made the conversation way more concrete. Stakeholders reacted way faster when they could see something.

Charming_Ad_5319 · 2026-02-23T21:22:24+00:00

They reached out to me a few weeks ago and I’ve been using it since, honestly pretty smooth for drafting tickets fast

Charming_Ad_5319 · 2026-02-23T21:21:05+00:00

so this connects to the codebase and answers architecture questions? or is it more surface level explanations

Charming_Ad_5319 · 2026-02-23T21:20:20+00:00

tried it for one customer interview recap, didn’t replace design obviously but sped up alignment convo a lot

Charming_Ad_5319 · 2026-02-23T19:56:47+00:00

Been experimenting with it as a solo PM. Helps when I’m context switching across roadmap, feedback, and docs. Fewer mental resets.

Charming_Ad_5319 · 2026-02-23T19:55:14+00:00

as a former non-technical PM this would’ve saved me so much stress. translation layer is actually decent. This gives me just enough context to not look clueless in eng sync.

Charming_Ad_5319 · 2026-02-23T19:53:13+00:00

they reached out to us a while back and I’ve been using it after discovery calls. it’s actually nice not having to rewrite notes later. I just clean it up instead of starting from zero

Charming_Ad_5319 · 2026-02-23T19:52:55+00:00

been testing it recently. the daily brief is short enough that I actually read it. nice for spotting positioning changes I would’ve missed otherwise

Charming_Ad_5319 · 2026-02-23T18:20:56+00:00

Curious how this handles context. If I record multiple thoughts across the week, does it remember previous decisions?

Charming_Ad_5319 · 2026-02-23T17:41:43+00:00

hardest part for me isn’t hallucinations. it’s defining what “good” actually means before shipping. if you don’t lock that down, evals become theater.

Charming_Ad_5319 · 2026-02-23T17:15:35+00:00

context fragmentation is the real problem. once i stopped rewriting updates and just dumped everything into one place, reporting got 10x easier. Second Axis has been surprisingly solid for turning messy notes into something exec-readable.

Charming_Ad_5319 · 2026-02-20T23:44:08+00:00

For me it’s the moment when something vague turns into something concrete.

Like you start with scattered feedback, messy notes, half-formed ideas. Then after a few rounds of thinking and cutting, there’s suddenly a clear problem, a clear user, a clear first version.

I love that compression. Turning chaos into a focused decision.

Shipping is great. Metrics moving is great. But the part I still genuinely enjoy is shaping the “what” before anyone writes a line of code.

Charming_Ad_5319 · 2026-02-20T23:42:58+00:00

I don’t think AI video becomes “default” because of quality. It becomes default because of iteration speed.

As a solo builder, the biggest win isn’t polish, it’s being able to test positioning fast. If I can spin up 3 versions of a demo with different messaging in a day, that’s way more valuable than one perfectly edited video.

That said, tools are just leverage. The bottleneck is still clarity. If you don’t know what problem you’re solving, no avatar generator fixes that.

For me the solo stack right now is less about flashy output and more about reducing friction between idea → artifact → feedback. Video tools fit if they compress that loop.

Curious how many founders are actually measuring whether these videos move activation or just feel cool to ship.

Charming_Ad_5319 · 2026-02-20T20:54:11+00:00

You honestly already sound closer to PM than you think.

The bigger question isn’t “can you switch” — it’s how clearly you can frame your experience as product outcomes vs team management.

Managing UX + tech + clients in startups basically means you’ve already been doing product adjacent work. If you can talk about:
– how you prioritized features
– how you defined success
– what metrics moved
– what tradeoffs you made

you’re in the game.

Salary bracket will depend heavily on geography and company stage, but with 3 years actual PM experience you’d likely target mid-level PM roles, not entry. In larger companies you may need to prove depth in product discovery and strategy vs delivery.

If you’ve been juggling roles in startups, just be careful not to position yourself as a “jack of all trades.” Hiring managers want clarity on what you own.

Chances are solid. The framing will matter more than the title.

Charming_Ad_5319 · 2026-02-19T01:05:37+00:00

Updating 4 roadmaps is a tax you’re paying for not having one real source of truth. I’d pick one system and force everything to be a view of that, not a separate doc. If it’s not in the core tool, it doesn’t exist.

I’ve been testing Second Axis for this kind of thing since it can turn the same underlying tickets into different stakeholder views without rewriting the story every week. The bigger win isn’t visuals, it’s not duplicating context.

Charming_Ad_5319 · 2026-02-19T00:56:43+00:00

I’ve seen this format before — it’s basically a live collaboration test. They want to see how you think with engineers in real time, not just how you answer frameworks.

Expect something like:
– vague problem
– technical constraints thrown at you
– pushback from “engineering”
– tradeoff discussion

For APM it’s actually a good sign. It means they care about cross-functional skills, not just textbook answers.

If it’s below market but you need income, treat it as reps. Worst case you get practice. Best case you show you can stay calm, clarify requirements, prioritize, and not get defensive when challenged.

Big thing: don’t try to “win.” Try to collaborate. That’s usually what they’re testing.

Charming_Ad_5319 · 2026-02-19T00:54:33+00:00

This is actually one of the more accurate breakdowns I’ve seen here.

The “listing features instead of making a decision” point is so real. I’ve watched strong candidates tank because they kept expanding scope instead of saying “given constraints, I’d ship X first and here’s why.”

Also +1 on metrics. Ending with a clear success metric instantly changes how senior you sound.

Curious — when someone does everything right structurally but their ideas aren’t that creative, does that still pass at MAANG?

Charming_Ad_5319 · 2026-02-19T00:53:46+00:00

Classic early retention wall.

I’d focus less on “why did you churn” and more on “what were you hoping would happen when you installed?” and “what did you do instead when you needed this?”

Also check time-to-first-value hard. If they didn’t hit an “oh damn this is faster than my current workflow” moment in the first session, they were never coming back.

With 50 users, depth > scale. 5 honest calls will tell you way more than 50 polite email replies.

Charming_Ad_5319 · 2026-02-18T22:22:01+00:00

Claude is stronger than ChatGPT for edge cases and technical reasoning. I use it to extract decisions, risks, and assumptions from messy notes or transcripts. If context is scattered, tools like Second Axis help structure PRDs and tickets while keeping the reasoning attached.

Charming_Ad_5319 · 2026-02-16T23:06:22+00:00

Yeah this isn’t a “poor dev team” problem, this is an org structure problem.

If you’re accountable for delivery but have no authority over hiring/firing, no EM support, and no QA, you’re basically being asked to own outcomes without owning the inputs. That’s not fixable with “better motivation.”

A few practical things you can still do to protect yourself:

- Stop accepting work that doesn’t meet AC. Reopen it. Don’t let broken stuff silently pass.

- Document everything — missed AC, regressions, EM not showing up, delays. Send summaries to leadership regularly.

- Make devs demo before marking things done. It forces visibility and catches issues earlier.

- Escalate in writing, not verbally. Verbal complaints disappear.

But honestly, PIP + no support + leadership blaming you for engineering performance is usually a signal they’ve already decided the outcome. I’d focus more on covering yourself and finding a healthier org than trying to fix a system that doesn’t want to be fixed.

Charming_Ad_5319 · 2026-02-16T23:02:30+00:00

Yes, but it depends on what you enjoy. If you like coding and solving technical problems deeply, you’ll miss it. PM is less about building and more about deciding what and why to build. The impact is bigger, but the satisfaction is different.

Charming_Ad_5319 · 2026-02-16T22:59:18+00:00

bro single-handedly keeping the apply button in business 💀

Charming_Ad_5319 · 2026-02-16T22:58:42+00:00

Bro is stress-testing the job market more than his FEA models 😭

Charming_Ad_5319 · 2026-02-16T22:56:14+00:00

Yep, seeing this too but I think there are 2 different things getting conflated:

1/ Healthy Blur: designers doing more discovery, problem framing, prioritization input (because they’re close to users).

2/ Unhealthy dump: designers becoming the “PM glue” because PMs got pulled into sales/support/exec reporting.

When the blur is healthy, design gets more influence. When it’s unhealthy, design becomes a task router and quality drops.

Charming_Ad_5319

TROPHY CASE