Best of LinkedIn: Digital Products & Services CW 38/ 39

00:00:00: This episode is provided by Thomas Allgaier and Frennus, based on the most relevant LinkedIn posts about digital products & services from CW-ThirtyEight&ThirtyNine.

00:00:09: Frenness is a BtoB market research company that supports enterprise product teams with building feature-by-feature competitive intelligence That shows exactly how their product stacks up against competition.

00:00:19: You can find more info in description.

00:00:22: So imagine someone just walking up to you and casually mentioning that they built a fully functional, multimodal AI insurance agent.

00:00:30: Right?

00:00:30: Just like

00:00:31: out of nowhere...

00:00:32: Yeah!

00:00:33: An application that can literally see through camera listen to the user's voice process visual evidence of car crash then actually challenge their claim if it looks suspicious.

00:00:43: Oh wow.. That is intense.

00:00:46: And now imagine did all this entirely on its own in about three hours.

00:00:51: See, that used to be a multi-month project for the whole team.

00:00:54: Like...a team of ten easily

00:00:56: Oh at least.

00:00:57: But today The mechanical ability to write code is just Well.

00:01:01: it's no longer the primary bottleneck in tech And that single fact Is causing this massive structural earthquake across entire industry.

00:01:09: Exactly and if you work in tech or digital transformation I mean That earthquake is happening right under your feet, right now.

00:01:17: So for this deep dive we've pulled together the most critical insights from recent discussions to explore exactly how AI's fundamentally rewiring How We Build Software?

00:01:26: How We Choose What To Build and honestly how product teams just have to organize themselves

00:01:40: design and engineering, they are completely dissolving.

00:01:44: They really are!

00:01:45: And the most obvious casualty in all this seems to be the traditional product requirements document or the PRD.

00:01:51: Oh The Good Old PRD Right?

00:01:53: For anyone who hasn't had the pleasure of writing one...the PRD used to be a gold standard.

00:01:58: it's essentially this massive blueprint.

00:02:00: I mean sometimes a twenty page text document where our Product Manager attempts to describe every single button behavior weird edge case of a feature before anyone is allowed to write a single line of code.

00:02:12: And it takes forever to right?

00:02:13: Forever,

00:02:15: but based on our research the PRD is dying.

00:02:18: It's basically being replaced by actual working prototypes.

00:02:22: Yeah and the underlying cause that shift Is what we really need to examine here.

00:02:26: Pavel Hurin shared a perspective On this.

00:02:29: they get straight To The core Of the issue.

00:02:31: What did he say?

00:02:32: He points out That functionally speaking

00:02:37: Wow, solved.

00:02:38: Yeah I mean it can be delegated to AI agents.

00:02:41: now we're reaching a point where in certain contexts engineers are even stopping their manual reviews of AI generated code because the agent's syntax is just that reliable.

00:02:53: That is wild to think about.

00:02:55: It is So if translating human logic into machine syntaxes no longer the hard part The role of product managers forced to evolve.

00:03:05: They can no longer just write specs and toss them over a wall to engineering.

00:03:09: they have To actually build

00:03:12: right which brings us perfectly back to that insurance agent example I mentioned at the top.

00:03:16: Mo Ali, actually shared That story.

00:03:18: it was a senior AI product manager who built that entire Multimodal Agent in Just three to four hours using A coding agent.

00:03:25: Three Hours?

00:03:27: It's hard to wrap your head around...it

00:03:29: really is!

00:03:33: It's like moving from being an architect who just draws the blueprints to a contractor, Who actually lays the first bricks.

00:03:39: You aren't just handing stakeholders A theoretical document To read anymore.

00:03:43: No you're giving them something real

00:03:44: Exactly!

00:03:45: You are handing Them a working application.

00:03:47: They can touch test and try to break.

00:03:51: And that analogy holds up perfectly When you look at how this changes The daily rhythm of your team.

00:03:56: Niko Pop shared An experience That illustrates the mechanics Of it beautifully.

00:04:01: He had This highly technical problem.

00:04:03: he wanted to visualize network attack paths and their blast radiuses.

00:04:07: Wait, Blast Radiuses?

00:04:08: Like in cybersecurity!

00:04:10: Uh yeah exactly.

00:04:12: Which is essentially mapping out exactly how far the damage would spread if a specific server was compromised And doing this across really complex graph database.

00:04:21: Okay, that sounds incredibly complicated.

00:04:24: Historically to even visualize the concept he would have needed to what?

00:04:28: Assemble UX designers system architects front-end devs

00:04:32: Right which means weeks of scheduling meetings.

00:04:35: Oh yeah aligning priorities playing cross functional waiting game.

00:04:39: just get a basic mock up.

00:04:40: But pop didn't do any of that.

00:04:43: Despite never having written single line of python in his life He sat down with clogged code.

00:04:49: Wait no Python experience at all

00:04:51: Zero.

00:04:53: He explained the logic, The AI wrote the Python he adjusted his parameters... ...the AI iterated and literally within hours he had a working prototype.

00:05:02: Pop's insight here is that the product manager Is becoming the conductor And the AI is the orchestra.

00:05:09: I love that framing.

00:05:10: Yeah

00:05:10: Product managers are undergoing what the industry calls shifting left Moving much earlier in the development life cycle to actually prototype the solutions themselves.

00:05:20: So if the PMs are shifting left to build, what happens to the engineers?

00:05:24: Well they have to shift right.

00:05:26: If this sheer monetary value of just typing out code is dropping, engineers must move closer to business logic.

00:05:33: They have become product thinkers who deeply understand customers' actual pain points.

00:05:38: The hard silos like eye design and you manage those are collapsing into a single unified discipline of continuous product development.

00:05:48: But let's look at the ripple effect of that speed, right?

00:05:50: Because Sachin Recky pointed out that because we can build so fast now our long-range planning horizons are completely falling apart.

00:05:59: Oh absolutely

00:06:00: Multiyear product roadmaps are essentially going extinct.

00:06:03: Teams or shrinking their planning cycles down to just six months and logically That makes sense.

00:06:09: Yeah You just can't plan that far ahead anymore.

00:06:12: Exactly if AI allows a team to build in four days what used to take for months And the underlying AI models are doubling in capability every single year.

00:06:21: Trying to plan a product roadmap for like, twenty-twenty nine is basically writing science fiction.

00:06:25: It really does But there's massive operational risk hiding at all that speed.

00:06:30: When you have product managers and designers People who historically haven't written production code Suddenly generating applications and pushing interfaces How do prevent them from accidentally bringing entire system down?

00:06:43: Great!

00:06:43: Like deleting the production database by mistake

00:06:46: Exactly.

00:06:47: Samya Sampath provided a crucial insight on how to manage this transition.

00:06:52: Her philosophy is that organizations need to build guardrails, not walls.

00:06:57: Okay let's break down the mechanics of that.

00:06:59: What is the functional difference between wall and a guardrail?

00:07:01: for software team?

00:07:03: A wall is process designed stop movement.

00:07:06: It's mandatory three-week security review committee or rule says only senior engineers are allowed touch prototyping environment It kills the exact speed that AI just gave you.

00:07:17: Right, it's just red tape!

00:07:19: Yeah... A guardrail on the other hand is an automated safety net.

00:07:23: It means setting up a sandbox environment—a safe playground where PMs can use AI to build and test actual code.

00:07:30: but the continuous integration pipeline automatically blocks that code from reaching live customers if it detects security flaw or performance strain.

00:07:38: Oh I see

00:07:39: It gives them the autonomy to move incredibly fast without accidentally bulldozing the actual live product.

00:07:46: So, this system catches error before user even sees it?

00:07:50: That makes total sense!

00:07:51: By the way if you are finding deep-dive valuable so far and want keep staying ahead of curve make sure subscribe for all our future additions.

00:07:58: we constantly scan the horizon.

00:08:02: Speaking of the horizon, we really need to transition into this second major theme in our research because if you followed logic that just laid out.

00:08:10: If AI makes building practically free and incredibly fast then execution is no longer a bottleneck!

00:08:16: Right... So..if Building takes hours instead months The risk isn't failing build product.

00:08:22: The risks are successfully building products that literally nobody actually wants.

00:08:27: That's exactly consensus forming among leaders like Dr Patrick Awad and Elena Linova.

00:08:33: They both highlight this really stark reality.

00:08:36: An AI can draft a beautiful PRD, it can write flawless Python and he could map out your database dependencies.

00:08:43: but an AI cannot sit in the room with frustrated customer and assess if problem is actually painful enough to pay for.

00:08:51: Judgment is more critical now than ever been basically because cost of producing garbage has dropped.

00:08:58: Let me push back on that logic for a second.

00:09:00: Okay,

00:09:01: go ahead!

00:09:01: If AI makes it so cheap and so fast to build features why shouldn't teams just build everything?

00:09:06: I mean if the cost of saying yes to a new feature is like an afternoon with a coding agent then why not throw everything at wall?

00:09:14: let users try it see what sticks.

00:09:16: Why is saying no still important?

00:09:19: That's great question but It assumes building a feature is time it takes to code.

00:09:25: Omar Salam offered a brilliant counter to that exact mindset.

00:09:29: He argues the absolute best product decision is often choosing what not-to build, because output is a terrible metric for success.

00:09:37: Wait...because even cheaply built features carry long term cost?

00:09:41: Exactly!

00:09:42: Think about cognitive overhead.

00:09:43: every user.

00:09:44: Every single button, menu or option you add into your product requires users process more information.

00:09:51: it clutters interface.

00:09:52: Oh, true.

00:09:53: It creates more edge cases that customer support has to handle.

00:09:56: it creates technical debt your engineers have to maintain for years.

00:10:00: Salon points out that True product sense is the ability To kill an idea early because The problem just isn't important enough.

00:10:08: you Have to save the user's attention For the core value of the Product.

00:10:12: That makes a lot Of sense.

00:10:14: You don't want A Swiss Army knife that Has fifty blades and can even Find one.

00:10:17: you need

00:10:17: Right.

00:10:18: And this actually explains a phenomenon that Kristoff Steinlener observed recently.

00:10:23: Last year, there were endless predictions about the rise of one-person AI product team.

00:10:28: Oh yeah I remember those!

00:10:29: The theory was...that one person with a suite of AI agents could define design code and launch whole startup by themselves

00:10:37: Which sounded amazing at the time

00:10:38: It did.

00:10:39: But Steinlenner point out..this prediction largely failed.

00:10:43: And the reason it failed is that assessing what's actually worth building requires human judgment across four incredibly complex dimensions.

00:10:51: Value, feasibility usability and viability.

00:10:55: AI can help with feasibility but navigating all four simultaneously Is usually just too complex for one single human brain.

00:11:03: Let's ground those four dimensions in a real-world story because Shownuck Mitra shared kind of painful example, he built a voice AI product specifically for restaurants.

00:11:14: It was an automated system to take phone orders and reservations.

00:11:17: Okay.

00:11:17: so how did it actually fare against those four dimensions?

00:11:21: Well they completely nailed the feasibility.

00:11:23: The technology worked!

00:11:25: It sounded totally natural And even scaled at about fifty locations.

00:11:29: Wow!

00:11:29: Fifty is impressive

00:11:30: Right but hit massive wall on value.

00:11:35: They realized too late that for a restaurant owner, an automated phone system is vitamin not a painkiller.

00:11:41: Ah I see where this going.

00:11:43: Yeah The real pain of a restaurant is usually staffing shortages or getting enough foot traffic on a Tuesday night.

00:11:51: It's not the marginal efficiency.

00:11:53: answering the phone Because it was just a Vitamin, the urgency wasn't there and customers didn't want to pay a premium.

00:12:00: And if they don't wanna pay a Premium immediately triggers a crisis in viability, the business model itself.

00:12:07: Running voice AI models processing audio and real time.

00:12:11: it's incredibly compute intensive and really expensive

00:12:15: Super expensive.

00:12:16: So if your cost structure is high because of the AI but you're perceived value as low You are forced to compete on price with a terrible profit margin

00:12:25: Exactly.

00:12:26: And on top of that, they struggled with usability.

00:12:28: The setup process for the restaurant owners was way too complex meaning the path to actually getting value took too long!

00:12:36: It is just such a stark reminder that building the tech is the easiest part of the equation right now.

00:12:41: Managing the intersecting risks-of-value, feasibility, usability and viability... That's the actual job

00:12:47: Right…and To manage those risks product teams historically rely on prioritization frameworks

00:12:53: True, but Akash Gupta had a very sharp critique of how teams use these frameworks today.

00:12:58: Before we get into his critique though for the listeners who don't live in product management jargon every single day what exactly do frameworks like Rice or Kano actually do in practice?

00:13:09: So frameworks are essentially structured scoring systems to help teams decide What To Build Next.

00:13:15: For example rice stands for reach impact confidence and effort.

00:13:20: You score a feature idea on How Many People It Will Reach how big the impact will be, how confident you are in those estimates and How much effort it'll take to build.

00:13:30: You do the math And basically spits out a score.

00:13:33: Okay pretty straightforward.

00:13:34: Yeah The Kono model is bit different though.

00:13:37: It categorizes features based on how they make user feel.

00:13:41: Is this feature basic expectation?

00:13:43: Like car having steering wheel Or is that a delighter like a car having heated massage seats?

00:13:50: Okay, so they are tools to organize human thought but Guptis as most people use them entirely backwards.

00:13:57: They learn the acronyms But they don't really understand the sequence of inquiry.

00:14:01: his point is that a framework doesn't make A decision for you.

00:14:03: it just answers a highly specific question

00:14:06: Which means if you ask the wrong?

00:14:08: Question The framework Just gives You a perfectly calculated Wrong answer.

00:14:12: Exactly If you need To figure out what fundamental problem the user Is actually trying to solve you might Use a Framework like jobs to be done.

00:14:19: If you already know the problem and need to rank potential solutions, then use Rice.

00:14:24: But...you have to deeply understand that before you can rank the solution.

00:14:29: And frankly no mathematical framework in this world is going answer most difficult question of all!

00:14:34: What are we willing say No-to?

00:14:35: Which brings us right back into the human element understanding customer.

00:14:39: Teresa Torres made a fascinating point about the limits of customer discovery in an AI World.

00:14:45: Oh I loved her.

00:14:46: take on it.

00:14:47: Yeah she noted.

00:14:48: if interview with customers They will usually only describe the friction that is immediately in front of them.

00:15:05: So an AI agent can listen to a customer interview and summarize their literal requests, but effective product discovery requires extrapolation.

00:15:14: A human PM has to take that minor complaint combine it with deep empathy for the user's overall daily workflow And invent a solution the customer couldn't even imagine

00:15:23: Right!

00:15:24: That limitation of AI perfectly transitions us into our final theme.

00:15:29: We've looked at tools getting faster in this strategy requiring deeper Human Judgment.

00:15:34: But you can have the most advanced coding agents and the sharpest strategic minds.

00:15:39: And if your organizational design is a total mess, The whole machine just grinds to a halt!

00:15:44: Ah...the messy reality of human coordination.

00:15:47: It's

00:15:47: always humans.

00:15:49: Kelvin Dart summarized this brutally well.

00:15:52: He said AI won't fix your product operating model.

00:15:55: it may help the mess move faster.

00:15:58: That is painfully accurate.

00:16:00: Fast AI analysis doesn't fix a culture of unclear accountability.

00:16:05: If your company still delivers work in project-based silos where teams assemble for three months, build a feature and disband you are just going to generate technical debt at the speed of light.

00:16:16: You still need the unsexy basics persistent teams obvious ownership and aligned goals.

00:16:22: Let's

00:16:22: talk about why that alignment is so hard to achieve.

00:16:24: actually Roshan Gupta brought up a really sharp analogy for cross functional alignment.

00:16:30: He compared product development to the old parable of The Blind Men and The Elephant.

00:16:34: Have you ever been in a room where six incredibly smart people are arguing over a product, And they all describing it completely differently?

00:16:41: Oh yes!

00:16:42: They're usually entirely sincere in their frustration.

00:16:45: Yes Because they are touching different parts of the elephant.

00:16:49: Engineering looks at this product and sees a scoping constraint and potential tech debt Sales touches it only see's missing feature that is blocking massive enterprise deal.

00:16:59: Finance looks at it and sees ballooning server costs.

00:17:02: And none of them are wrong?

00:17:03: Exactly, none of the more wrong.

00:17:04: but None Of Them Are Seeing The Whole Animal.

00:17:07: You Can't Fix That Room By Trying To Prove Sales Or Finance Wrong!

00:17:25: Helene Amsterdam-Kopel mapped out how AI is specifically changing the role of the product owner.

00:17:31: For years, a lot of product owners were forced to act as glorified backlog librarians.

00:17:37: Backlog librarians?

00:17:38: Yeah!

00:17:39: Their days were just consumed by writing user stories defining acceptance criteria and organizing JIRA tickets

00:17:46: which easily eats up forty hours a week.

00:17:48: but doesn't AI essentially automate that entire backlog librarian job?

00:17:53: I mean, an AI can listen to a planning meeting and instantly map out all the dependencies in JIRA.

00:17:58: Does that mean the product owner is basically out of a

00:18:01: job?".

00:18:01: No it means the routine of the job has gone but the purpose remains.

00:18:07: Comple makes a really crucial distinction here... AI replaces activities not accountability.

00:18:13: Interesting!

00:18:14: Yes The machine can generate a list of twenty conflicting dependencies but the AI doesn't know company politics.

00:18:20: It does not know that delaying feature A will anger your most important enterprise client, while delaying Feature B will demoralize you best engineering team.

00:18:28: The human still has to own those trade-offs.

00:18:32: We are leaving an era where we could get paid just to maintain a list and entering an Era when companies were paying purely for judgment to navigate trade offs that an AI cannot comprehend.

00:18:42: But to make sure the whole organization can navigate those trade-offs smoothly, you need systemic connective tissue.

00:18:48: This is where Genie Jacques's insights on product operations really come into play!

00:18:52: Yeah and ProductOps is still a fuzzy concept for a lot of organizations... how does she define it?

00:18:58: And she defines it as the work that happens before its officially anyone's job.

00:19:02: When two different product teams accidentally build redundant solutions to this same customer problem because they just don't talk with each other, or when executives can't figure out how much of R&D budget is actually mapping their strategic priorities... That friction?

00:19:15: Is a lack of product ops!

00:19:16: If product and engineering are responsible for building products customers love ProductOps is responsible for building the organization that produces those products.

00:19:25: It's designing the rhythms, the feedback loops and ensuring a strategic decision made by the board on Friday actually translates to what an engineer builds on a Tuesday.

00:19:34: But there is

00:19:36: a catch.

00:19:37: Even with perfect operations clear frameworks enlightening fast AI There is one structural bottleneck.

00:19:44: technology absolutely cannot fix.

00:19:46: Mackenzie Hughes pointed out that sometimes the most expensive bottleneck in a product organization is the CEO.

00:19:54: Ah, The over-involved executive!

00:19:56: How does it typically manifest?

00:19:58: It manifests as micromanagement disguised its passion.

00:20:01: You see CEOs hire incredibly talented product leaders promise them full autonomy and then immediately insert themselves into every single tactical decision.

00:20:10: Oh I've seen that happen.

00:20:12: They want to approve this six month roadmap They want to debate the pixel colors on the landing page, and they demand instant status updates on really niche customer requests.

00:20:22: And because they carry the title of CEO The organization treats every random opinion they have as a five-alarm fire.

00:20:28: It completely derails the team's focus.

00:20:30: Yeah...and

00:20:31: the irony is three months later that same ceo will demand to know why the product team isn't moving faster

00:20:37: because they don't realize they are the wall, not the guardrail.

00:20:41: And you cannot out prompt a micromanager if the CEO doesn't actually delegate authority.

00:20:47: all that AI efficiency in the world just means The team can pivot to the CEOs bad ideas faster

00:20:53: Exactly!

00:20:54: AI exposes organizational dysfunction Because it removes old excuse of slow execution when coding is practically instant.

00:21:02: any delays your system were clearingly obvious and usually point back human bottlenecks.

00:21:07: We have covered a massive amount of ground today.

00:21:10: We started with the death of the massive PRD and PMs becoming builders, we debated why deciding what not to build is the most critical survival skill when execution costs zero And we broke down the messy realities of cross-functional elephants in CEO bottlenecks.

00:21:27: It's fundamental rewiring.

00:21:30: if I can leave you one final thought as you go back AI is giving product teams unprecedented speed, but speed without direction just means arriving at the wrong destination faster.

00:21:43: The next time you sit down with an AI agent to build a prototype or plan a feature pause and ask yourself a difficult question are you simply using advanced technology to efficiently automate the creation of something that shouldn't actually exist in the first place?

00:21:58: If you enjoyed this episode new episodes drop every two weeks.

00:22:01: Also, check out our other editions on Cloud Insights and Sovereignty, ICT & Tech Insights, AI and Agentec Systems, Sustainability in Green ICT, DefenseTech and HealthTech.