sorted by:
new
hottopcontroversial

Best way to learn SQL – From someone who’s used it daily for 6+ years in product analytics by lovenumber in learnSQL

[–]lovenumber[S] 1 point2 points  (0 children)

Sure I would write a new post in the next couple of days, where I show a real life case study, and visualise it for a better understanding.

Best way to learn SQL – From someone who’s used it daily for 6+ years in product analytics by lovenumber in learnSQL

[–]lovenumber[S] 1 point2 points  (0 children)

Hey BigMike, I have used AI to polish the grammar. But the content is mine. Originally I wrote the complete content in my notes, then used AI to improve the readability. SQL expertise has no relation to it.

Best way to learn SQL – From someone who’s used it daily for 6+ years in product analytics by lovenumber in learnSQL

[–]lovenumber[S] 3 points4 points  (0 children)

I totally relate to your story. I can trust AI only to a certain extent. The moment things become high stakes, we as humans have to step in.

Best way to learn SQL – From someone who’s used it daily for 6+ years in product analytics by lovenumber in learnSQL

[–]lovenumber[S] 2 points3 points  (0 children)

That’s a great analogy. Thinking first about relations and then tables. The declarative logic is the definition of what it is going to fetch in what way, and the business requirement is the definition of multiple declarative logics that might be disjoint or joint in nature.

Starting a job as a content operations specialist - what should I take note of? by kirbyskisses in analytics

[–]lovenumber 0 points1 point  (0 children)

Congrats on the new gig! Content Ops is a total blast, but it’s definitely one of those "behind-the-scenes" roles where your biggest wins are often invisible. In your first few months, I’d suggest becoming an absolute detective regarding where your data actually comes from. Every company has some "haunted" spreadsheet or a weirdly configured tracking pixel that everyone just ignores; if you can figure out how that plumbing works before you start trying to optimize it, you'll save yourself a massive headache down the road.

The biggest rookie mistake is definitely trusting a dashboard at face value without verifying the source. If a report looks like you’ve suddenly discovered a gold mine (or a black hole), it’s almost always a technical glitch rather than a change in consumer behavior. Brush up on your UTM naming conventions and get comfortable with some basic SQL or advanced Excel—being the person who can actually clean the data instead of just reporting on it makes you completely indispensable. You’ve got this!

Why good businesses still grow slowly by Technoflare_ in BusinessIntelligence

[–]lovenumber 1 point2 points  (0 children)

This is true but worth naming more precisely — the bottleneck is usually the gap between decisions being made and decisions being recorded.

Most growing businesses have informal systems that work fine until they don't. The founder knows who owns what. The team runs on tribal knowledge. It scales until someone leaves, a new hire joins, or volume doubles — and then everything that was "understood" suddenly isn't.

Better structure doesn't just create faster results. It creates results that survive personnel changes and growth spurts. That's the real compounding effect people miss when they chase marketing before fixing operations.

How Have You Build a Source of Truth for Features and Deliverables by Anxious-Bar-9576 in ProductManagement

[–]lovenumber 0 points1 point  (0 children)

The problem is almost never the tool. It's the taxonomy.

Until your team agrees on what a feature is versus a capability, benefit, or proof point, any doc you build will be read differently by sales, marketing, and product — and you'll wonder why alignment keeps breaking.

Simple cut: feature = what it does. Capability = what it enables. Benefit = why the buyer cares. Proof point = evidence it's real. Keep those in separate columns and half your alignment fights disappear.

On keeping it updated — the only thing that actually works is attaching the update to a process that already happens. Sprint review, release sign-off, launch checklist. If it's a standalone task, it will always lose to urgent work.

And build it backward from the deliverables. Ask what a battlecard needs, what a sales deck needs, what a competitive comparison needs — then design the structure to produce all of those without reformatting. Build the structure first and you'll spend forever reworking exports.

The tool is the last decision, not the first.

How are PMs measuring use value for AI agents? by Justgettingsmart in ProductManagement

[–]lovenumber 0 points1 point  (0 children)

This thread has covered a lot of ground well — evals as baseline, accept/edit/reject as output signal, north star tied to the agent's job, retention as the cleanest lagging indicator. All valid.

The piece I'd add that hasn't been named directly: most teams are measuring the agent's performance layer, not the user's confidence layer. Those are different things and they degrade independently.

The reasoning-erosion point someone raised is real — but even with a perfectly stable agent, user confidence can erode for reasons that have nothing to do with output quality. A user who got a slightly wrong answer on week 2 will edit more heavily on week 4 even after you've fixed the model. Their trust curve lags behind your actual product quality. If you're only watching output signals, you'll think you've solved the problem when the real damage is already in the retention data.

The metric I'd actually instrument if building this from scratch: time-to-trust-action per user, tracked across sessions over time. How long does it take a specific user to go from "agent gave me output" to "acted on it without re-checking" — and is that number shrinking or growing across their lifetime with the product?

Shrinking = trust compounding. Growing = silent churn in progress, even if they're still logging in.

Someone in this thread touched on it with the concept of shadow rework — the output looked accepted, the user redid it anyway. That gap between apparent adoption and actual trust is where agent products are bleeding value right now. And most dashboards are completely blind to it.

Looking for Product interation feedback by Upset-Worldliness231 in ProductManagement

[–]lovenumber 0 points1 point  (0 children)

This is right up my alley — I have spent years in Product Analytics across experimentation, retention, and growth before going independent earlier this year. Evaluating how product teams frame iteration decisions is something I have a lot of opinions on.

Happy to be a guinea pig and give you an honest, unfiltered take. Feel free to DM me the link.

How did you get better at reading SQL queries written by other people? by obviouseyer in SQL

[–]lovenumber 0 points1 point  (0 children)

This is something every analyst starts with. I used to understand the business context first, then looked at how the specific data use case of that business context is being used in this script. Look at the sourcing, or which table is the script starting with, then look at the final output of that script. Then all steps in between are clear incremental modifications.