Image for post
Image for post

How to improve your product management and leadership practices

Product management is a relatively new discipline that keeps evolving rapidly. Every week, there are new articles about product development best practices that industry leaders are following. This deluge of information can make it difficult to understand what practices to follow and how to look for improvement opportunities in one’s own work and team.

Moreover, this constant evolution means that what is considered best practice today might be outdated tomorrow. For instance, earlier this year, news broke that Spotify is no longer following the “Spotify model”, which for a while was hailed as the model for a large scale product development organization rooted in agile and lean principles. …


Image for post
Image for post

Some things I’ve learned along the way

I’ve been in product management and product leadership roles for half a decade now, and I’ve picked up a thing or two along the way. In this post, I am sharing 25 bite-sized lessons that I have learned over time — I hope they can help make you a better product manager, too.

1. Start with Why

A product manager should link the team’s work to the vision — both the company vision and a vision for their specific product area. Shared purpose provides intrinsic motivation, so communicate “why” first rather than what or how.

More thoughts on why you should “Start With Why” in this short talk by Simon…


Image for post
Image for post

Building your product muscle, one hour at a time

I usually don’t write much about breaking into product management — I believe that there are others who have more valuable insights to share than I do, and I therefore focus my writing on what I have learned while working as a product manager and product leader. Whenever I do share advice for people wanting to break into product, it’s only because I have a perspective or idea that I consider reasonably unique. Today, I want to share one exercise to get better at product management job interviews.

There are several books and countless online resources to help land a product manager job. Two books that I can personally recommend are “Cracking the PM Interview” and “Decode and Conquer”. When I was first preparing for product management interviews myself, I liked the former for its comprehensive approach and overall advice, and from the latter I particularly liked the framework for addressing product interviews. …


Image for post
Image for post

Why implementing hyped frameworks won’t get you far

The product development world is enamored with best practices and frameworks. Hardly a week goes by in which there isn’t another set of processes and practices being discussed and at times even hyped: from the Spotify model to Basecamp’s Shape Up, from Scrum to SAFe, from Design Sprints to RICE prioritization, people are looking for plug and play solutions that will make them more effective and efficient at designing and shipping products that are beneficial to their customers and their business.

However, it is a delusion to think that implementing any of these best practices and frameworks top to bottom will be a silver bullet making you more effective, lean, or agile. The reasons for this are manifold. You or your team might lack the right mindset or experience to make the practice a success. You might have a completely different organizational context from seniority over decision making to structure. You might have a culture that is not compatible with the chosen practice. The practice might require a different industry or type of product to yours. In short, there are many reasons why implementing a given practice might fail to realize the results you are hoping for. …


Image for post
Image for post

Why you should let your teams figure out what to build

One of the central best practices of modern product development is the empowered product team. An empowered team is a cross-functional team, composed of product, design, and engineering, that is tasked with solving specific customer problems in ways that serve the business. In other words, these teams have goals for customer and business outcomes, not goals in terms of the output (products or features shipped).

However, most organizations do not follow this model, but instead have delivery or feature teams that build product features that someone else (leadership or business stakeholders) has scoped, prioritized, and put on a roadmap. …


Image for post
Image for post

Delivering as many good ideas as possible doesn’t create great products

In many product organizations, quarterly goal setting exercises and roadmaps discussions amount to a negotiation between product leadership and/or product management and the rest of the team, how many features can get built in a given time frame. The backlog is long and there are so many good ideas on the table. There is the general mindset of “the more good ideas we deliver on, the better our product will be”.

Product leaders often instill this mindset in their product managers and product teams by setting stretch goals and asking the teams to deliver as much as they possibly can.

Product managers are guilty of it, too: version 1 of a feature gets scoped as a “good enough” 80:20 version, 80% of the value with 20% of the effort. …


Image for post
Image for post

Why teams without conflicts don’t tend to produce great products

One of the most counterintuitive aspects about great product teams is that being a part of them isn’t always comfortable. It’s not all smooth sailing: there are frictions and disagreements between team members, differences in working styles, and clashes of perspectives.

Some teams think that this discomfort is something to be rooted out: they hire for “culture fit” which they define as how easily the prospective team member would get along and collaborate with the rest of the team. This approach is flawed, though. Great outcomes require discomfort. Great product teams will therefore always have some level of discomfort.

Of course, not all discomfort is good. If the climate in the team is toxic, if people are openly hostile towards one another, or if there is no psychological safety, it will negatively impact the well-being and performance of the team. The question, then, is how to achieve the right level and kind of discomfort. …


Image for post
Image for post

Outputs? Outcomes? Even considering both is insufficient.

“Outcomes over Outputs” is a mantra that has swept the product management and product development community over the last couple of years, even leading to a major book outlining the concept. At the core of the paradigm is the insight that just pushing teams to deliver ever more output (= shipping more product features) is not a good way to build great products — you need to focus on outcomes for the customer and in turn for the business instead.

In this article, I will outline a few ways in which this advice is at best incomplete and at worst flawed, and describe ways in which to improve the concept. Don’t get me wrong: I’m not advocating the return of a singular focus on output. …


Image for post
Image for post

Why your product needs a growth loop to succeed

“Build it, and they will come” is an old product development adage. It basically says that if you build a great product addressing a need that people have which currently goes unmet, then you will have no problems finding customers. They will simply come to you. And occasionally, for truly amazing and novel products, that is indeed the case: fueled by word of mouth and the love of existing customers, the hockey stick growth curve is achieved. Most products aren’t like that, though.

Today, there’s an abundance of software available for all kinds of use cases. There are more than 2 million apps available on the iOS and Android stores alone, and an uncounted number of SaaS and desktop apps. It has never been easier to develop and ship software, so on the flip side, it has become harder for that software to get discovered by potential customers. This proliferation of software also means that many broad use cases applying to large groups of people are already well served. With easy world wide distribution through app stores or the web, it then makes sense to focus on more niche groups of customers, but word of mouth as a user acquisition channel might not work as well for those narrow audiences. In summary, just by building a product that solves a problem people have, you can’t guarantee that those people actually discover and start using your product. …


Image for post
Image for post

Most of your ideas won’t work — and that’s okay

Developing digital products is inherently risky. Big software projects face delays, explode in cost, or get canceled all the time. Not just the effort involved in building the product is uncertain, though. More fundamentally, even the value itself is questionable. Consider the example of Quibi, the short form, mobile focused video subscription service launched to much fanfare in April, only to see disappointing download and engagement figures. Clearly, consumers did not find the offering particularly compelling and valuable, despite a lot of up front planning and big investments into the product.

This risk is also not limited to new products. Changes to existing products are affected as well. It frequently happens that product teams launch what they consider improvements to the product, only to see lack of user adoption, reduced engagement, or even backlash. …

About

Jens-Fabian Goetzmann

Experienced product leader, previously at 8fit, Yammer, BCG. Currently working on something new.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store