More features, more problems (PWW #3)

Let's dive into the problem of adding too many features to a product. And I share my experiences creating a custom GPT.

More features, more problems (PWW #3)
Image by DALL-E

Hi!

When building a product it's very tempting to get sucked into the feature factory. You create lists of ideas for "cool" feature ideas and requests from stakeholders/users. You prioritise them and make a roadmap. It's easy to think that - if you can just tick off all of these boxes - you will end up with a great product.

Sorry to burst your bubble but this will not work. Even worse: every feature you add will reduce your future velocity forever.

This week I'm highlighting a great article about this. Hopefully it can stop you from becoming a feature factory.

On a different note: I'm also highlight my personal experiences building a custom GPT to act as a side-kick for Product Owners and Product Managers. I'm sharing my experiences in building this custom GPT, and the key learnings so far. Be sure to scroll down and check out the results!

Have a great day 👋

Wouter


Worth reading

More features, more problems by Maarten Dalmijn

This article really hit home for me, as it's something I've believed strongly for years.

A feature doesn't create value. What a feature makes possible is what creates value.

In the real world there is no direct correlation between building a feature in your product, and actually adding value to your users. If only things were that simple…

I see so many teams and POs falling towards being a feature-factory. They just build whatever stakeholders want. Naively thinking that this is the way to build a great product. In reality they are digging their own grave.

Every feature you create adds complexity. Your codebase gets larger, you create the potential for more bugs, and you have to keep spending time to keep features running. Fairly quickly you end up getting bogged down in maintenance. Unable to deliver any new value. Even worse: you are losing sight of what actually brings value to users.

Martijn argues that if you never remove features, you don't know what features are actually necessary and which aren't.

I would argue that becoming a feature factory is the greatest threat a product team faces.

Have you ever removed a feature from your product?


Going Deep by John Cutler

During the ZIRP (Zero Interest Rate Policy) era of the last 10-ish years companies have rapidly grown in number of FTEs. Especially tech companies have been on a non-stop hiring spree for the last few years. They were just blindly hiring people, sticking them under a manager, and accepting that there was no work for them to do. All for the sake of "preventing competitors from attracting more talent".

This crazy bubble has caused issues for (senior) managers. They've had to deal with increasingly large teams and adding more and more layers of middle management or team leads. The effect is that most managers are no longer aware of the day-to-day challenges in their own teams.

Enter 2023. Interest rates skyrocketed. The almost unrestricted flow of capital into tech companies ground to a halt. Economic conditions started forcing companies to face reality: they had over-hired and could not afford to continue being inefficient. Investors and boards started demanding more fiscal responsibility.

2023 became the year of efficiency, as Mark Zuckerberg called it. What followed were massive lay-offs throughout the tech sector (and other sectors were not immune either). This was also the time where most managers found out they were woefully under-informed about what was going on in their teams.

Lay-offs mean making trade-offs. What is the effect of losing X resources in a specific team? What are the key resources in a team? And which could we do without? What will all of this do to strategic organisation goals? Getting this wrong could have very problematic results. Cutting the wrong resources from a team can make it grind to a halt.

In this article John Cutler argues for (senior) managers to go deeper. Understand more of the details of what's going on day-to-day. Not to micro-manage. But to understand and have better context.

It isn't about "flattening" the org chart but rather about ensuring people who can discuss reality are in the room. In short, the current emphasis on "going deep" and "getting into the details" is a reaction to an overreaction and overstretching of the org chart. So, it is time for a reset without over-reacting again. Yes, spend time to understand what is happening and be a better advocate during more challenging times. No, don’t heap on even more asks for detailed trade-offs and detailed plans, so you can play defense.

I agree we are way overdue for a reset in leadership. During the most recent tech boom the answer to every problem has been: just raise more money and hire more people. This has never been a smart strategy to start with, but it's impossible now.

Leaders need to dive deeper into what their teams are doing. And they need to lead by example in emphasising efficiency, scrappiness and foster a "spend it like it's yours" mindset.

I believe most tech(ish) companies can do the same with drastically fewer people.


Lightning round

Some other stuff I have been reading this week:

Eliminating normalized deviance from software teams
In my experience, normalized deviance is the most common problem plaguing dysfunctional software teams. Its symptoms include technical debt, heroism, alert spam, and frequent outages. Too many…
The Evolution of a Product Manager: 3 Stages of Consciousness
Much like the stages of human evolution, many Product Managers go through 3 distinct phases. In this light-hearted guide, I’ll explore these stages and the valuable lessons they offer along the way, hoping to provide you with valuable insights to help navigate this complex field.

What's been keeping me busy: custom GPTs

Since OpenAI recently launched the ability to create custom GPTs I have been playing around with them. If you are not familiar: custom GPTs allow you to create a custom version of ChatGPT that is tailored towards a specific use-case.

For example: you can have a ChatGPT that is focused on being a creative writing coach or one to help analyse data. There is now a custom GPT "store" within ChatGPT where you can browse other peoples creations.

Product Whisperer GPT

I have been working on my own Product Whisperer GPT. This is created specifically for product owners and product managers, to help them in day to day work or be a mentor.

This GPT has been fed with specific instructions, and some documents and descriptions I have written over the years.

The main reason I'm experimenting with this: to understand how a custom GPT will differ from the standard ChatGPT. And to be completely honest: the difference is not mind-blowing (yet)…

Comparing my custom GPT to normal ChatGPT (GPT-4), the outcomes are not exactly the same but fairly similar. The advantage of the custom GPT is that it is more stuck to the context of product management.

Key learnings so far

  • Using a custom GPT works particularly well if you have a narrow use-case (such as a fitness coach). Broader use-cases don't seem to benefit a ton from creating a custom GPT.
  • You can "train" your custom GPT on files you upload (for example PDF's). This can be great for giving the GPT access to specific information. But keep in mind: people have been able to engineer prompts that spit out the contents of those files. So don't upload private information.
  • This is only the beginning. OpenAI have create a basic store to browse GPTs. I would imaging the ability to monetize custom GPTs will come soon.
  • I will keep tweaking and experimenting with Product Whisperer GPT. Feedback is much appreciated, so feel free to take it for a spin!

Subscribe to Product Whispers

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe