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. …


Image for post
Image for post

Own the team direction but be willing to course-correct

Product management requires a broad set of skills. A lot of people, including myself, have written extensively about how these skills can be categorized. However, none of these categorizations can ever be complete or fully accurate, simply because the product manager role varies so much between organizations. In this article, instead of an attempt at completeness, I want to shine a light on a particular set of complementary skills: leading and learning. Successful product managers need to be able to lead and take charge but also willing to learn and change course at all times. …


Image for post
Image for post

Why you should stop hoarding product improvement ideas

Familiar product management scenes: a salesperson raises a feature request, gets the response: “good idea, we’ll put that on our backlog”. A hackathon happens, lots of good ideas duct-taped together in a couple of days; the product team dutifully collects and documents the ideas. A product team brainstorms improvement ideas, lots of sticky notes on the wall; some get prioritized to be built right away, the rest gets put on the backlog. Fast forward 6 months: none of these ideas on the backlog have been build. Another 6 months: still nothing. The people who raised the ideas get disillusioned, frustrated.

Scenes like the above happen in a lot of companies. People working in the product development organization want to solicit input and ideas, they want the rest of the company to be able to contribute. …


Image for post
Image for post

Counterintuitive advice for product development

It is an often-repeated piece of management advice to demand that team members “bring solutions, not problems”. The reason for this advice is to empower employees to solve problems they encounter, reduce management bottlenecks, and thereby to improve the overall performance of the team.

In product development teams, however, often the opposite demand is appropriate: bring me problems, not solutions.

At first glance, reversing this advice sounds strange. Aren’t empowered product teams what we want? Surely, if asking for solutions empowers the team, then asking for problems must disempower them?

In reality, it’s not so simple. Potential product changes are often discussed in the form of feature ideas. These might come from a number of places — customers, team members, executives, etc.… Feature ideas, however, are solutions. Of course, these solutions have an underlying problem, but it is important to explicitly move up to the level of the underlying problem. …


Image for post
Image for post

How product leaders can help their organization effectively execute

One of the essential areas of responsibility for product leaders is setting up the processes of the product development department. For an overview, read my high-level article on product leadership responsibilities, or continue reading for a deep dive on processes that are relevant to the product organization.

To set up any organization, you need to put in place an organization structure as well as processes. A product development organization is no different: once the org structure is in place, you also need to establish the right processes.

The processes in a product development organization can be thought of as having three…

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