Nothing is perfect. Nothing is permanent.
Which is a pretty disconcerting way to go through life. Humans are hardwired to look for meaning, for stability, for something lasting.
But nothing is.
In Dark Star Safari, Paul Theroux mocks faithful missionaries, suggesting instead to:
“look for truth in nature… nothing is complete, everything is imperfect, nothing lasts.”
That can sound fatalistic. But maybe it can also be liberating.
That big life decision you’re stressing about? Just make the best choice with the information you have today and realize it’s not going to define everything after.
Stuck working and re-working a feature…
The very word can strike fear and loathing in the heart of many product managers.
The relationship between product management and business stakeholders in many organizations is often strained and sometimes toxic. Stakeholders view the product team as an internal service organization and PMs as project managers that exist to build features. Meanwhile, PMs complain that the business doesn’t care about customers and doesn’t understand technology.
How do you change this dynamic?
In my opinion, a healthy product/stakeholder relationship comes down to two ingredients: empathy and competence. Ultimately, the burden is on the PM to demonstrate both: empathy for…
Many product teams work in reverse. We focus on what we’re going to build and then asked the question, “how will we quantify the impact?”. Sure, we probably have a general idea of what we want to accomplish from the outset, but that outcome isn’t the genesis of the feature request.
What's more, the product team is usually not to blame for this process of reverse engineering. That because, in many organizations, the roadmap is still being set by business stakeholders. The product team is being handed a list of features to build. Sometimes the PM is being asked to…
By most accounts, 80% of all new product features are failures, meaning they are either met with a yawn and a shrug from your customer or — worst of all — actually make your product harder to use. Some teams are hitting it out of the park and finding success half of the time.
In other words, building a new product is risky. There’s a lot that can go wrong.
When you ask most product teams how they work, they’ll say agile. But agile is only half the story.
Agile outlines a product delivery process; literally the “manufacturing flow” for…
A lot has been written about OKR’s — Objectives & Key Results. In fact, if you’re not using them, you can be made to feel a bit like a dinosaur in the tech industry. While I’m no zealot of the framework, I do think it’s one of the more effective ways to organize a company to drive alignment, increase transparency and empower teams to solve problems.
The tricky part is implementing it properly.
There is a ton of good content describing the OKR framework, so I won’t waste space on that here. …
When I first started out in product management, I thought it was my job to write requirements. Like Moses, I envisioned the PM descending from Mount Sinai with her requirements; a technical version of the Ten Commandments (only thicker).
I was quick to learn that there is a fundamental problem with requirements: they imply a one-way street. The PM produces the requirements and the engineer delivers. This is essentially a client/vendor relationship, and it leads to a lot of bad products.
In fact, it’s not the PM’s job to define the solution at all. It’s her job to define the…
Call it “building to learn” or “iteration by design”… good product teams have this embedded in their DNA.
Let’s face it: building tech products is not like manufacturing widgets on an assembly line. We’re creating things that, by-and-large, have not existed before. It’s a creative process involving a high risk of failure.
While our goal is to address these risks during product discovery and…
In life and work, there is never enough. It’s human nature to want more than what we currently have. As a result, you never have enough money to buy, or time to do, everything you desire.
The answer, of course, is obvious. If you can’t resource your way out of the problem, you have to reduce the need. In Buddhism, it’s letting go of desire.
The sage who’s fully quenched rests at ease in every way; no sense desire adheres to him whose fires have cooled, deprived of fuel. All attachments have been severed, the heart’s been led away from…
Creating clarity in an organization is like peeling back the layers of an onion. Only when all your team members understand each layer, from the aspirational product vision to the strategy to the objectives and key results, are you able to create an empowered product team focused on solving problems.
If employees only have visibility on the quarterly objectives and no understanding of the long-term vision, it’s hard to build passionate engagement. You’ll likely end up with what Marty Cagan calls a team of mercenaries instead of missionaries. …
The most important part of product discovery is defining the problem. However, even for seasoned product managers, it’s a step that is sometimes forgotten or often glossed over. That’s human nature! We think we understand what we’re solving for and our mind jumps immediately to potential solutions. We’re creative creatures and we like solving problems. After all, the solution is what we’re paid to build and what delivers tangible benefit to our customers.
So, while we know we should put the “why” before the “how”, it’s not always easy in practice. That’s where framing comes in.
Framing should be a…
Husband, father, traveler and tech enthusiast.