Product Initiative Reviews
It is ironic that some high % of teams do retrospectives for their team. (process, output, blockers, etc.), but not retrospectives for their work.
The online whiteboard of Kristofer Palmvik
It is ironic that some high % of teams do retrospectives for their team. (process, output, blockers, etc.), but not retrospectives for their work.
The basic idea is to use common (but salient) objects, activities, and ideas to spark a conversation.
Knowing what to build and "telling the future" is a sign of confidence. Features Are Real.
Without persistent models, teams are always chasing their tails. Quarterly OKRs should not feel like a "big deal". But they are exactly that when either 1) teams have to dream up their OKRs from complete scratch without a persistent model to guide them, or 2) OKRs are a cascaded down and teams lack context.
I love the idea that we use forcing functions to snap us out of automatic action. To have a conversation. To consider information.
Continuous improvement internally is a lot like improving a product externally. It is tempting, but dangerous, to skip steps.
Much harder is understanding how very different organizational cultures can produce equally positive outcomes for customers, team-members, and "the business".
Stripe is not going public any time soon. It is at the very beginning of a decades-long journey during which it will compound the internet’s growth, and compound with it to become one of the world’s most valuable companies. If Stripe is successful, it will transform the economy, and I’ll be here telling everyone to appreciate it even more.
...you could ditch annual planning all-together and do something more continuous, but whenever I say that’s possible no one believes me (except for the people doing it)
Over time interviewing, I’ve found that I mainly screen for one key thing: giving a shit.
When Person A has to communicate a complex idea to Person B, she invariably is going to leave out a lot of the details and say something accidentally too simple. This process of translating the mental image of a complex system to something human-readable (usually words or pictures) is information compression, and what Person B then understands from that message ("the compression") is the decompressed image.
The problem with something that does lots of jobs is that it is very easy to send the wrong message. Say someone joins your company. Do they pick up on all the nuance?
You can LARP your job in person (holding lots of meetings, staying late and getting there early as a show of ‘presentism’) and digitally (sending lots of emails, spending a lot of time on Slack, or whatever group chat platform your organization uses).
Here’s a fun activity you can do with your team. What words do we use that seem to cause confusion?
I’ve come to believe that a lot of what people see as "skills" on the part of well-known product companies, is actually freedom and space. The work is difficult, but the good (or at least rewarding) kind of difficult. At a core level, the organization has confidence that the teams will contribute meaningfully, and the surrounding architecture, strategy, and org structure support that.
What would your compelling, human-centric North Star Metric name look like? What do you WISH it could be? Start there...
People will nod like crazy when they hear about the ills of high WIP or running individual projects...and go right back to it.
These individuals know that organizations are not an idealized Venn diagram of "aligned incentives" glued together by meritocracy. They sense the cracks and the edges and want to help and support, and know if they don’t, no one will.
While ConstitutionDAO did not win the bid, the effort captivated the internet. It showed the promise of DAOs and Web3 but — most importantly for SatPost — it birthed some truly glorious memes.
I work with dozens of product teams around the world. In helping them to build a discovery capability — the ability to develop consumer insight— I provide this checklist
There is no such thing as hybrid, your options are office-first or remote-first.
When looking at why things are working (or not working) in organizations, we all have our explanation biases – leadership, organizational design, incentives, management, skills and experience, empowerment, complex adaptive systems, systems thinking, "mindset", safety and resilience, diffusion of innovations, psychological safety, strategy, and more.
Why did this happen? Let’s take a look at the basics of Clubhouse as a business, not as a cultural phenomenon.
I’m going to share with you what my regular work-week looks like as tech-lead of Aftenposten
Here are the top three lessons I’ve learned: 1. Avoid broad outcomes 2. One outcome per team 3. Keep metrics simple
The success of its ad business is a 180-degree turn for Amazon. In 2009, Bezos famously said "ads are the price you pay for an unremarkable product or service".
None of the tools in their company captured what actually happened, and who was involved (except for that tiny bit at the end, and their calendars).
I’m not a process freak, but I do believe teams should have their house in order. You can get by with very little process overhead. If you figure out a minimally viable version of these eight things, you will be further along than most product teams in the world. Pulling this stuff together may seem boring, but the boring bits can be so important.
No problem exists on an island. Every problem is a nested solution to a higher level problem. Every problem is a collection of nested problems.
Prioritization means cutting things that are valuable so I can double down on even bigger goals. If I’m not disappointed by a few items on my "cut" list, like a product I’m excited about but don’t have time to work on or an interesting discussion I can’t join, I’m not cutting hard enough.
It has something to do with them being young, concentrating intensely on the right problems, and remaining open to fresh perspectives.
I would encourage more airlines to start thinking about how to incorporate multi-modal transportation in a more seamless way. All these examples raise the question of whether 2022 can be the year where transportation can become more efficient.
Most product leaders spend their time doing the necessary evils of their job and get sucked into too many meetings. Here are the areas where I encourage product leaders to spend more (and less) time
If you needed a hackathon in order to demonstrate a product idea, then that usually means in my experience that your weekly workflow doesn’t allow for room for suggesting new ideas.
If you are a mess explorer, consider whether it helps you to expose all of the mess in public. Are you overwhelming people? Is it helping your cause?
What if your subscription was an NFT in the blockchain? Think about some of the interesting things you can do with NFTs
I call the pattern: We’re Trying to Do Product, But We’re Handed an Incredibly Overwhelming List of Prescriptive Projects Disguised as Problem Statements With Overly-Ambitious Business Impact Forecasts
As a product leader you can’t expect everyone to give you "actionable feedback". And you can’t expect everyone to give you feedback in the same way.
For every feature we build, I try to think not only about how it feels for the people who use it, but also how it feels for the people who don’t. Does it add more cognitive load? Could they stumble upon the feature and be confused? Will they see the feature every day and never use it, and over time, start to feel like the whole app is "not meant for them"?
Imagine how much faster we could grow if we had those insights in real-time and could take quick action to respond. Here are a few tactics that have helped me get hard but useful feedback.
Good product management is all about choosing the "right" product paths, but "right" is only obvious in hindsight.
What if Twitter had set itself up as as creator business and made the consumer user base secondary? What if the real users were the 1% creators (journalists, entertainers, thinkers, writers)?
When you publish your thoughts on Twitter, you are doing labor for that company. Yes, you get followers, but you can’t take them with you.
The most exciting thing about Netflix’s culture and feedback systems is the methods themselves depended on experimentation and ongoing feedback. We started with a traditional annual review system, tried more frequent reviews, and eventually eliminated the formal, written review systems in favor of a culture that advocated and helped coach employees to embrace candor and to give and receive feedback more effectively.
A compilation of the most interesting findings and implications people have dug out of ChatGPT (with my added commentary, of course)
I believe there’s a lot to gain from ChatGPT so I want to dedicate a post to its virtues and merits: This one will help you learn which are the best applications for ChatGPT—without entering gray territory—and how to get the most out of it.
The NPS Effect explains why less-than-optimal things can persist in business for a long time—even when a good % of the team wouldn’t recommend those things to a friend.
Many product teams do research, but don’t take the critical steps of synthesizing and disseminating learnings. They either fail to convert information into knowledge, or that knowledge stays trapped within the pod and doesn’t help educate the broader product / engineering / design org.
Instead of assuming ChatGPT is great for anything related to text, writing, or language, we should approach the problem of its applicability with that top-down perspective: Let’s understand the characteristics that best define the chatbot, and from there draw a line to those tasks where those traits aren’t bugs but features.
I’ve been pondering on one big problem: if something catastrophic were to happen to all the papers in Schibsted, how can we ensure that Aftenposten is the first to restore service to readers?
There simply isn’t such a compelling use case for a language that relies on being type-safe when TypeScript can do that for you 90% of the way. Adopting a niche language comes with a bunch of downsides on top of that, like a smaller potential hiring pool
Paying down product debt is an essential process for maintaining high availability and engineering efficiency. One of my favorite sayings on this topic is that "availability is the most important feature." In any decent size company, there is no feature your product teams will launch in a year that will yield more revenue than just keeping the app or site running.
In contrast to human-to-human communication, interacting with computers is unnatural. Computers are aliens to us. That’s why consciously learning prompt engineering is key—it won’t come to us as naturally as we’d like. People who don’t know this try to force the computer to adapt to what they know (human communication) and that’s precisely why they fail to get the results they want.
The implication: first, choose your fairness wisely. Choose the groups you want to be fair toward: gender, race, age, and income. And understand that there are trade-offs.
I was treating "teaching users your product" as 1 big job, and in reality there are potentially 3 sub-jobs hiding behind it. When you teach your product, you actually teach 3 different dimensions: the interface, the domain, and the benefit.
This dynamic is why letting things slip and waiting until bad things happen, or focusing only on lagging indicators, is dangerous. Waiting seems rational. "Why fix something before it is an issue? We've got work to do!" The problem is that, almost by definition, when that goes wrong, you'll probably have to deal with the "fog" of many layered factors and an impaired ability to diagnose and address problems.
Panels and fireside chats have become my favorite kind of public speaking — they require so little prep! — and moderating can be even more fun than being a panelist. Throughout my career, I’ve learned so much by asking amazing people to talk about what they’re passionate about.
To tell the difference between a harmful cascade and an effective tree/graph, ask if it is a high-conviction model. If people shrug—wondering if their actionable goals will impact sustainable, long-term growth—you probably have a low conviction model and a harmful cascade.
So much can be learned from this very basic question: What are you working on right now, and why is it the most important thing you could be working on?
When I think about strategy, goals, plans, roadmaps, etc. I think about them across four dimensions: Level, Depth (or Specificity), Time, Frame
The way we build modern software products is in teams. While I’m sure there are people that have all the requisite skills such as product vision, management, user experience, analytics, and software development to build something all by themselves, it’s almost guaranteed that a better product could be built by leveraging people with stronger skills in those areas.
Staff Engineers are primarily technical leads operating on a longer time horizon. This involves strategic work but also setting standards, simplifying complex solutions, adding clarity and mentorship.
In general, when I see teams stressing out about prioritizing individual features (or prioritization frameworks), I always recommend that they step back and paint a picture of the high-level curve they are dealing with. That is often far more telling than the effort/impact-specific tactical bets.
Are you waiting for people to provide feedback in surveys or to speak their managers?If so, is that going to be enough? Go through the reasons above and make sure that you’re providing channels and help where needed.
One strategy to familiarize team members with failure is to conduct a Failure Workshop. Think of it as a tabletop exercise on failure in a safe environment. The workshop's objective is to "stay in the failure" while fostering a supportive space for peer interaction.
Use managed services for as long as possible. We did ourselves a big disservice by leaving Heroku after only a few months. We should have stayed on it for years - there was so much time wasted managing servers that could have been done for us during critical early days.
If speed is so important, why do most companies go so slow? I have concluded that it boils down to one (or all) of these problems.
We hate working on old, complex software we don’t understand. It turns out— we hate it so much that we’re prepared to throw in the towel and roll the dice at a shot with another company. Granted, relationships with peers and managers play a significant role in this, that can’t be denied and it is not refuted or strongly correlated by the paper.
If your company is currently mired in discussions about productivity, realize that this is a proxy discussion for something else. Like many things, it is about power, narrative, and worldviews. It is probably about a clash—paradigm, professional, cultural, or otherwise.
Software is much more like a garden than a mechanical entity like a car. We plant the initial seeds (start designing and building), water and nurture it (make updates and enhance features), and periodically have to prune (refactor) and weed (remove bugs and vulnerabilities). A product requires constant attention to grow and adapt to its environment (user needs, technological changes, and market trends). It's an ongoing process of growth, adaptation, and care.
Whether you are a new team member, a senior leader, or a government official, knowing the history of the organization and the people is critical to integrating and leading. Take the time to learn where the organization has come from if you’re the new person and if you’re the person that’s been around a while, teach the new folks that are joining.
I was working with a leader recently, and they asked me why a team might knowingly commit to work they couldn’t feasibly get done. Why didn’t they say no?
As organizations transition from startup to scale-up, and eventually to established enterprises, the leadership mantle may need to shift to individuals whose personality traits are congruent with the altered operational dynamics.
When you design a product with the traditional economics worldview, you aim to understand and cater to a user's fixed preferences. But in the behavioral economics realm, the belief is that preferences are created at the time of decision-making—thus products have an influence on shaping them.
You only have so many levers to deliver more predictably. You can reduce batch size, minimize work in progress, collaborate more closely, work in shorter time boxes, focus more, start together/work together/finish together, limit the reactive tasks you get pulled into, and limit multitasking and context switching.
Supplements! A god damn jungle. Grab your machetes and let’s go!
Before you pick any type of architecture, what you need to ask yourself is how much cognitive load capacity your organization has available to meet the demands of the product you want to deliver and then adjust accordingly.
The power of hope coupled with empowerment within organizations is not to be underestimated. It forms the bedrock of a conducive work environment, spurring individuals and teams towards achieving remarkable milestones. By nurturing hope and empowerment, organizations are not just building a positive work culture, but are actively investing in a future replete with possibilities and success.
Organizational transformation is a marathon, not a sprint. Persistence is key to recognizing the uniqueness of each organization. While there's no one-size-fits-all guide, a structured and thoughtful approach significantly enhances the likelihood of success.
I will highlight both obvious and subtle signs that you work in a feature factory and describe 16 indicators I've noticed in Product Management over the last 15 years. These can be divided into three major categories: a dysfunctional process, a shattered culture characterized by unclear roles and responsibilities leading to dysfunctional collaboration, a lack of strategy and vision (or at least both badly defined)
Within the phenomenon of psychological safety are observable traits such as taking turns while speaking, being aware of other’s feelings, and clear norms. Google researchers eventually determined that a number of factors were involved in making some teams more successful than others but psychological safety was the most important.
Skilled pragmatists are too smart to wade into conflicts or political maneuvering. They work within the system. They are under-challenged and bored at work but are resourceful enough to scratch those itches in other ways. They aren't lazy—doing the bare minimum and stopping—but they also don't go "above and beyond" because they are inherently skeptical that it is worth it.
From years [decades] of watching master programmers, I have observed certain common patterns in their workflows. From years [decades] of coaching skilled journeyman programmers, I have observed the absence of those patterns. I have seen what a difference introducing the patterns can make. Here are ways effective programmers get the most out of their precious 3e9 seconds on the planet.
I don’t think they expected it to depict Vikings as Indian and British kings as Black. That’s not what diversity means. That’s a result of specification gaming.
What do leaders who are skilled at navigating complexity know how to do? What do they do differently? What would you observe if a leader had these skills?
I often speak to people who lament the fact that their company strategy doesn’t match the "good strategy" descriptions discussed in books, talks, research, and popular examples. “With so much information out there, why don’t we have a real strategy?”
Creating a strategy doesn’t directly change anything for our customers. Customers don’t care about our strategies — they care about their experience with the product in their hands. So for a strategy to be useful, it actually has to change our behavior as a team to create better customer outcomes.
If the product management trendiest books are so powerful, it's because they are inspiring, they make us hope and dream. But it's also important to remember that these books are not meant to reflect reality, let alone a scientific analysis of what makes tech companies successful worldwide.
You’ll be surprised how much fun the job gets when you are given a problem to solve vs a bunch of features to build.
Here's how to safely learn/practice product even if your org feels like an irreformable feature factory.
This post will explore three popular models for product teams: Sprint, Story, and Backlog-Centric, Team and Mission-Centric, Engineer-Centric (with Rockstar PMs)
Your team is burnt out. They are not getting anything done. Work is "low quality". You can see and feel those things. But what you are seeing is an output of something—the downstream effects of other things happening.
Here's a fun way to structure a quarter. It's a nice change of pace and helps a team go through the "full cycle" of learning, building, measuring, learning, etc. 2w research and discovery, 6w get something out to customers, 4w iterate, 1w tie up loose ends
When both groups are operating from their higher brain functions, delightful experiences can be created. But when one or both parties falls into a mode of just reacting from their “reptilian brain”, things start to go sideways.
But what makes one strategy better or worse than another in terms of keeping oriented? The answer is coherence.
The Cutler Variation of Goodhart's Law: In environments with high psychological safety, trust, and an appreciation for complex sociotechnical systems, when a measure becomes a target, it can remain a good measure because missing the target is treated as a valuable signal for continuous improvement rather than failure.
How do you ensure these meetings are more than just another item on your to-do list? Enter the 4Ps framework: Preparedness, Personal, Performance, and Peers.
Emotional labor, epistemic relativism, perspective-taking, navigating cognitive dissonance, and reflexivity are not "free." It's work, and it is draining. It is draining to navigate environments where (most people) are confidently sure of themselves or at least work hard to portray that.
Every time I’ve focused on these, my product has intuitively gotten better. And it gives the whole team a sense for how we can work together to improve quality, in a way that's deeply felt by customers.
What does an unmotivated developer feel? Unappreciated (and/or underpaid). Lonely. Bored. Stuck. Apathetic. When a developer quits, it’s almost always because they feel one (or more) of those 5 things.
The team reworked turn-by-turn street directions to include navigational landmarks to help orient people, signal turns, confirm direction, and error correct. The team worked through several iterations before finally landing on a solution that emphasized landmarks, but also subtly included road names
Processes like OKRs fall apart not because people don't understand them but because they lack meaningful feedback, have unclear goals, are buried under conflicting incentives, or have learned to distrust the system. Zombie processes arise when we don't address these factors.
Writing is important to me because it’s integral to how I think, how I lead, and how I contribute to my community. And I believe it can be the same for you. Whether it’s to clarify your thoughts, to share your knowledge, or to document your journey, writing is a practice worth developing.
Founder Mode is a joke. It’s for the weak. You want the truth? Founder Mode is pure delusion—a comfortable lie for those too scared to go all in. You want to level up? This is Ultra Founder Mode, where the intensity never drops, the pressure never lets up, and excuses are obliterated.
Generally, the guidance is: don’t forget good software engineering practices just because an AI is involved.
Every major advance that made coding easier—high-level languages, frameworks, cloud computing all led to more software, not less. AI will follow the same pattern: by lowering the barrier to entry, it will flood the world with more software, more systems, and more complexity. And that means we need more engineers, not fewer.
Every company out there has evolved a working culture over time that is the sum total of the pre-existing biases of every employee, and especially of the leadership team. Status quo bias is an obvious contender here. Fear comes into play.
By branding the player, YouTube wasn’t claiming ownership over the video content. But it was creating a signature look and feel around each video that was unmistakably YouTube.
The most effective driver of AI adoption isn't better models or improved accuracy—it's success stories from peers and respected figures in professional networks. Rather than push AI, encourage communities that will push AI.
GÖR DEN GREJEN DÅ. Med papper, sax och lim. Skulptera. Bygg. Slipa. Inte fan vet jag men skapa den på riktigt. Ta sen en bild på den och återkom. Då ska jag ge dig en like. Jag tror till och med att jag kommer le.
The product itself still has a long way to go, but the system that can build a great product is largely there—and it’s continuously getting better. The product is, after all, a lagging indicator of the quality of the socio-technical system that produces it.
Traditional product teams often follow a linear flow: PM defines, designer mocks, engineers build. But that model breaks down when you're building AI-native products. We’re not designing screens for users to click—we’re building systems that interpret intent and act on it. That changes everything. To get it right, everyone needs to be involved early: product, design, frontend, backend, data. Discovery and delivery collapse into the same loop. Feedback is faster. Outcomes are less predictable. The system learns from use, so you need tight, collaborative cycles to learn with it.
What will happen when we blindly apply Big Agile + premature AI tooling to core health services and patient data? Financial services? Social media and the spread of misinformation? Government infrastructure? Military infrastructure? It’s 2025 and software engineering is the backbone of pretty much everything. But for all its prevalence and influence, most people don’t have the technical literacy to even grasp the basics.
So maybe the answer isn’t fewer meetings. It’s better ones. Meetings where everyone comes prepared. Where we solve problems together. Where ideas are tested, refined, and built in real time. In short: meetings that look less like a lecture, and more like a room full of smart people, standing at the whiteboard, figuring things out together.
My key critique is that the article follows a classic rhetorical move. It begins with the language of empathy and belief, such as "I want to believe" and "it pains me," but it ends with a moral judgment. What starts as a reflection on the challenges of building empowered teams becomes a statement about individual character, framed as a lack of ambition.
To get things done, breaking through silos is rewarded. "We are one team here! Pull in who you need, cut across silos, take initiative!" But when it comes to feedback, concerns, "pulling the andon cord", or questioning the current strategy, front-line team members are expected to route everything up the official chain. Boundary-spanning is great for delivery, but not for dissent.
The good thing about intrinsic motivation is that you can design the workplace for that. With simple actions, you can get outstanding results.
Jag tror att resa är bra, att det utmanar och frigör. På olika sätt för olika människor. Vissa kan bo på Bali i ett år och inte lära sig någon om landet de flyttat till eller människorna där. Andra åker på en charterresa med helpension och livet förändras helt. Men samtidigt tänker jag att just nu, i denna tid i världshistorien måste vi omvärdera allt. Om vi väntar med att resa annorlunda så kommer vi inte ha en planet kvar
What do we actually see when teams are more product-centric? I’d like to share a post version of the talk below. None of these behaviors are all-or-nothing. There will always be situations where you do more of some and less of others. The point is to use them as prompts for reflection and conversation.
1. Write a list of the test scenarios you want to cover. 2. Turn exactly one item on the list into an actual, concrete, runnable test. 3. Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them)- 4. Optionally refactor to improve the implementation design 5. Until the list is empty, go back to #2
Turning a feature on doesn’t guarantee people will use it. Adoption depends on motivation, action, and recovery when things don’t go perfectly. This one banner illustrates three lessons product teams can apply right away.
So how are you systematically checking that the output your product spits out is good? Smart product/AI leaders have been shouting for months about how AI product managers need to get good at building evals (Lenny Rachitsky, Aakash Gupta, Teresa Torres, Hamel Hussain & Shreya Shankar, to name a few). So I’m shocked to see how many AI product builders have not thought this through, and leave it at a random vibe-check every now and then.
Concrete thinkers zero in on tangible details. They take things at face value, prefer clear steps, ask “how” and “what,” and anchor on specifics like flight times, budgets, or examples. Abstract thinkers reach for concepts and patterns. They ask “why,” connect ideas across domains, and zoom out to purpose, meaning, and future possibilities.
We talk endlessly about economic incentives and housing stock and walkability scores and innovation hubs, but almost no one is talking about the moment a human shows up with a suitcase and a dog and realizes they don’t know where to buy a plunger or who might go for a coffee with them.
I stället för att enbart prata om begränsningar i skärmtid tycker jag att vi borde prata mer om hur vi skapar en tillvaro där barn, ungdomar och vuxna kan och vill göra annat. Hur bygger vi platser, aktiviteter och sociala rum som konkurrerar ut skärmen på egna meriter?
It took me a few years to truly grasp the difference. If you’re valued, you’ll likely see a clear path for advancement and development, you might get more strategic roles and involvement in key decisions. If you are just useful, your role might feel more stagnant.
A “feature” is never just a button or a feed; it’s a nudge in a complex human ecosystem. When we optimize for convenience or connection, we often trigger second-order effects that are difficult to unwind.