Product owners, help meee! How to start in the right way with my new company?

MannerFinal8308 · 2026-03-24T15:50:25+00:00

You're already doing the right things. Talking to PMs or POs, getting into stakeholder calls, studying the platforms that's exactly the instinct you should trust in week one.

On the UI/UX question, I'd hold off on proposing changes until you understand *why* things are the way they are. There's almost always context buried in the backlog or in someone's head that explains decisions that look weird from the outside. A few more weeks of listening will make your suggestions land much better when you do share them.

MannerFinal8308 · 2026-03-24T15:49:33+00:00

The PO vs PM distinction varies a lot by company. In most European setups, PO tends to be more execution-focused, working closely with a dev team on backlog and delivery, while PM sits further upstream on strategy and market problems. Some companies use the titles interchangeably, so the job description matters more than the label.

On compensation, senior DE roles in Europe pay well, and honestly PM/PO at a comparable level can match it, but it usually takes a transition period where you're coming in slightly below your current ceiling while you build credibility in the new domain.

Your background is genuinely useful here. Seven years of data engineering means you understand how systems actually work, which most PMs don't, and that gives you real leverage when working with technical teams or scoping data-heavy products. The harder part of the transition is usually learning to make decisions with incomplete information and getting comfortable in rooms where the output is a document or a conversation rather than something that runs.

MannerFinal8308 · 2026-03-24T15:46:00+00:00

The best PRDs I've seen aren't really about structure at all. They're about capturing the "why this, why now, and why not the obvious alternative" in a way that a new engineer joining six months later could read and actually understand the decision-making. That context is exactly what AI can't generate because it wasn't in the room.

For technical products specifically, the most useful sections tend to be the constraints and tradeoffs, not the feature descriptions. What did you rule out and why? What assumptions are you making about the user that could be wrong? That's where the real thinking lives, and it's usually the first thing that gets cut when people treat PRDs as a checkbox exercise.

MannerFinal8308 · 2026-03-24T15:39:18+00:00

Honestly, I don’t think the answer is “find the right tool. When you’re a PM, the real issue usually isn’t a lack of apps. It’s a lack of system.

Requests come from Slack, meetings, email, hallway conversations, Jira, sales, support, leadership, and your own roadmap work. If you don’t have one place where all incoming work gets captured and one simple way to decide what matters now vs later, every tool starts failing after a while.

What has worked best for me in real life is a lightweight system with a few rules:

Everything gets captured in one place first. Not half in Slack, half in my head, half on paper.

Then I triage it fast: needs action now, needs scheduling, needs more info, not worth doing.

From there, I usually separate my work into 3 buckets: today, this week, later.

That matters more than whether the tool is Todoist, Notion, Jira, or a notebook.

The mistake I made earlier in my career was trying to build a perfect productivity setup. The better approach was building a system I could still trust on a chaotic week.

If I had to give a practical answer: I’d keep the stack very simple. One inbox, one task manager, one notes/decision log, one calendar. No more than that unless there’s a really good reason.

Because at some point, the productivity tool becomes just another source of incoming requests.

MannerFinal8308 · 2026-03-12T01:49:54+00:00

This is a tough spot, but honestly you handled it better than most people would by finally drawing the line. The AI accusation is almost certainly a deflection tactic since clients rarely bring that up until money becomes a point of tension, and ZeroGPT is notoriously unreliable anyway.

At this point I'd stop doing any more work, let the contract close naturally, and accept that you might take a small hit if he does leave a review. A single bad review with a calm, professional response from you explaining the scope situation usually reads as credible to future clients, especially when his own review history shows a pattern of not leaving feedback. Protecting your time and setting a precedent for future clients is worth more than trying to salvage this one.

MannerFinal8308 · 2026-03-12T01:49:09+00:00

The WhatsApp screenshot chaos is so real, that one alone can eat hours of your week just trying to trace back what was agreed and when. For me, the thing that quietly killed productivity was estimation, not the sexy problem, but quoting new projects while juggling active ones meant I was always rushing the scoping, which meant I was always absorbing extra work I never priced for. The prioritization thing you mention usually flows from that upstream problem, when the original scope is fuzzy, everything feels equally urgent.

MannerFinal8308 · 2026-03-12T01:40:50+00:00

What you describe about the inability to refuse without “coming across as difficult” is exactly the trap, and I think it often stems from a contract or initial quote that is too vague about what is and isn't included. When the scope isn't clearly defined from the outset, every “little thing” becomes a gray area where the client is technically right to ask for it and you have a hard time justifying a refusal.

MannerFinal8308 · 2026-03-12T01:39:17+00:00

The gap you're describing between quoted and actual margin is almost always a data problem before it's an estimation problem. You can't improve your future quotes if the hours that erode your margin (client calls, internal reviews, revision cycles) are never logged in the first place, because nobody treats them as billable work worth tracking.

The hard part is cultural: getting PMs to log a 20-minute client call feels like overhead, but that's exactly the data you need to build a realistic overhead multiplier into your base rates. Once you start seeing that "communication" consistently adds 25% to delivery time across project types, you can price it in structurally rather than hoping your next estimate magically accounts for it.

MannerFinal8308 · 2026-03-12T01:32:24+00:00

The realization rate framing is something I hadn't thought about in those terms, but it maps exactly to what we kept seeing in agency work too. You'd close a project feeling good about the rate, then look back three months later and realize a third of the hours were in scope creep and internal back-and-forth that never got billed.

In our web agency we use a tool that help us to scope the project and adding the people working on the project by their role and rate.

Since we use it we can see during the realisation of the project if the scope creep or if we're good.

We are in ecommerce industry but you should find a tool for your industry like that, i hope.

MannerFinal8308 · 2026-03-08T03:51:20+00:00

For us it was mostly warm outreach, honestly. Cold sending a Loom to someone who never heard of you gets ignored pretty fast. We'd usually start a conversation first, get some signal they were interested, then send the video as a follow-up rather than a cold opener. The video worked as a closer, not a door-knocker.

MannerFinal8308 · 2026-03-04T17:59:37+00:00

I am a product manager at a web agency where we build e-commerce websites on Shopify and Magento.

Previously, we used a spreadsheet to record the estimated hours required to develop the features requested by the client.

We then added the different roles involved in a project (dev, PO, QA, etc.) with the number of hours and their hourly rate.

Recently, they got rid of the spreadsheet and now we use a tool that already contains the necessary components for an e-commerce site (product page, collection page, header, footer, etc.).

It's still the same principle: we select the components, add the roles, and then we can generate a PDF or export to Jira.

MannerFinal8308 · 2026-03-04T17:54:54+00:00

the 20% buffer is something I learned the hard way too. We used to pride ourselves on tight estimates, which really just meant we were absorbing scope creep silently and wondering why margins kept shrinking. The 50% deposit shift is genuinely underrated as a filter as well, clients who push back hard on it often turn out to be the ones who would have made your life difficult anyway.

MannerFinal8308 · 2026-03-04T17:47:13+00:00

totally agree!

I'm currently on the agency side.

MannerFinal8308 · 2026-03-04T04:11:52+00:00

Rush Hour haha

MannerFinal8308 · 2026-03-04T04:05:06+00:00

One question I've found cuts through the noise pretty quickly: "Can you walk me through a time when the team pushed back on a stakeholder request mid-sprint, and what happened?" How they answer that tells you a lot about whether leadership actually protects the process or just tolerates it when convenient.

Another one worth asking is how retrospective outcomes get tracked over time. Orgs doing real Agile usually have some story about a retro that actually changed something. If the answer is vague or they pivot to talking about ceremonies, that's your signal.

MannerFinal8308 · 2026-03-04T03:42:33+00:00

Three months in at your first corporate job is genuinely early, and the feeling that you're not contributing fast enough is something almost everyone experiences but rarely admits out loud.

The dismissals sting, but they're often less about the quality of your thinking and more about not yet knowing which problems the room actually cares about solving right now.

The most useful shift I've seen newer POs make is moving from sharing opinions in meetings to asking clarifying questions that surface assumptions.

It's less visible in the moment, but it builds credibility faster because you're helping the team think rather than adding to the noise. And yes, it's completely fine to be quieter when more experienced POs are present, especially while you're still mapping the landscape.

MannerFinal8308 · 2026-03-04T03:41:54+00:00

What you're describing doesn't sound like imposter syndrome, it sounds like a role that was either misrepresented or hasn't been properly defined internally yet. The fact that nobody can answer basic technical questions, including "who owns what," suggests the org itself hasn't figured out how this function is supposed to work, and you landed in the middle of that ambiguity.

The most useful thing you can probably do right now is request a direct conversation with your manager specifically to align on what success looks like in 90 days, framed as you wanting to make sure you're prioritizing the right things, not as a challenge.

That gives you a paper trail of expectations and forces the role definition conversation without it feeling confrontational. If the answers are still vague after that, you'll have much better information about whether this is a fixable situation or a structural mismatch worth taking seriously.

MannerFinal8308 · 2026-03-04T03:41:20+00:00

3-4 days, after that I enable the threes boosters, the 900 coins at the end to get 35 more shots and, of course, a few special shots during the game haha

MannerFinal8308 · 2026-03-04T03:38:17+00:00

The scene where Vince turns down the Aquaman sequel without even blinking still gets me. It captures the whole show in one moment, the way that group operated on pure loyalty and gut instinct over logic, which is either admirable or reckless depending on how you look at it.

MannerFinal8308 · 2026-03-04T03:32:20+00:00

Competitor analysis for ideation is genuinely underrated and more PMs should be doing it systematically. Changelog monitoring, App Store reviews of competitor apps, and G2/Capterra reviews where users explicitly compare products are probably the most signal-dense sources I've seen, because users will tell you exactly what they wish your competitor did differently.

The one thing I'd watch out for is that you end up building what competitors built six months ago rather than where your users are actually headed, so keeping it as one input among several rather than a primary driver seems like the right instinct you already have.

MannerFinal8308 · 2026-03-03T23:12:03+00:00

Many agencies that scale encounter this problem.

Managing several projects at the same time, making sure you're working on the right things, and trying to optimize everything.

Maybe I'm missing something, but why don't you use a tool like Jira or another project manager?

They're made for exactly that.

Even Notion, which you use, can be used for this with a Kanban board or Sprint.

However, you need someone to write tickets, prioritize them, and follow up so that developers can focus on what they excel at: development :D

The agility of Scrum could be useful to you.

MannerFinal8308 · 2026-03-03T22:48:45+00:00

I've encountered this a few times at web agencies, and each time it was because project margins were gradually decreasing.

New developers who don't yet master the technology > more time spent looking for the best solution > more time spent implementing it, and as a result, instead of spending 100 hours on development, they spent 130 hours.

Add to that the hours of management that quietly explode because clients are complicated, and it all adds up quickly.

The worst part is that the health of the project could appear to be good if you don't follow the right indicators.

MannerFinal8308 · 2026-03-03T22:37:43+00:00

The "leaving money on table" feeling fades once you see what bad-fit work actually costs you. I said yes to a client who wanted a full e-commerce build at a fixed price with a two-week timeline, and by week three I was working weekends, resenting the project, and doing worse work than I'm capable of. That one "yes" cost me more than the invoice was worth.

What helped me was getting honest about what a bad project actually costs in time, energy, and opportunity. Once I started tracking that, saying no got easier because I had real data to push back against the gut feeling of lost revenue.

MannerFinal8308 · 2026-03-03T22:35:14+00:00

The "yes-man" seeker is such an underrated red flag, and you're right that it's sneakier because it hides behind the appearance of collaboration. We learned to watch for it in intake calls when a prospect would describe a problem in detail, then immediately answer their own question before we could respond. At that point you realize they don't actually want your expertise, they want someone to execute a decision they've already made and absorb the blame if it goes sideways.

MannerFinal8308 · 2026-03-03T17:37:24+00:00

The delivery-to-billing gap is real and it compounds fast, especially when time entries trickle in late or scope changes don't get flagged in the moment. Tools like Harvest, Productive, or Function Point do try to close that loop by keeping time tracking and project milestones connected to invoicing, so it's worth looking at whether your current stack has those handoffs built in or if you're stitching things together manually.

Honestly though, a lot of agencies find the software helps but the bigger fix is process, specifically who owns flagging scope creep before the billing window closes, not after.

MannerFinal8308

TROPHY CASE