Most teams build too many features
A case study where Journey Mapping helped to build less
The most common fallacy I see in product development is that teams build too many features.
I worked with a product team that grappled with this issue a while ago. They were in the habit of building elaborate solutions, inevitably leading to countless hours in meetings and running into growing complexity. It was a pattern I’d seen multiple times before.
Usually, it unfolds like this: A team identifies a problem to solve. It looks very promising, and they start fleshing out the presumably perfect solution in their heads. They begin to define details, the designer creates screen flows, and the engineers discuss how to solve tricky technical challenges. They spend days in meetings before producing anything tangible and discovering more and more things to build.
Approaching every discovered problem or proposed capability by trying to solve it completely leads to endless meetings and paves the path for a grinding work mode in the months and years to come. The mechanic works roughly as illustrated below.
Building everything means there is already lots of specification work before anything can be released. More features are enabled by more code, which grows technical debt and maintenance work, and of course, it comes with introducing more bugs. The engineering team gets increasingly overwhelmed by the amount of existing functionality. Meanwhile, the product manager will be eaten by defining, prioritizing, and managing expectations for the next big thing. At the same time, everything is blocked by tackling the technical complexity and iterating on existing features to make them work as expected. As a side effect, the company culture is getting used to asking for extensive new capabilities from the team.
You get my point. The more you invest in getting better at building bigger, the more you will fall into the trap. So, let’s get out of this habit and start building smaller.
But how do we find what not to build?
A straightforward way to emerge from this mess of overthinking and overbuilding is to map the first idea in a journey, look for the low-effort solution to get something released or tested, and validate whether it is worth investing more in.
Back to the product team, which was on the path to overbuilding. Part of their product was a course booking system. They heard from the course coordinators and students that if there are no future course slots open, the coordinators wanted to know if there is demand, and the students wanted to pre-register for the next available course.
The team started to ideate on how they might solve this. They immediately discussed what capabilities they needed and looked into technical constraints and ways around them.
It quickly grew into an extensive list of features they would need to build. I started working with them when they were already discussing how they might create an entirely new notification system for coordinators, trainers, and students, among other similar complicated features. You see, they went into several rabbit holes. And, of course, they weren’t delivering anything for this identified problem because when they weren’t discussing this new capability, they had other significant features in their active building pipeline.
Map it out
I started to map the journey with the team. In around 30 minutes, we had the rough sequence of things they considered building. We marked what already existed and what would be new with sticky colors.
While mapping the journey, it was already clear that the flow had many open questions and challenges. We deliberately omitted many details and edge cases to get a first overview and avoid stumbling into endless detailed discussions that might not be relevant.
After we had the overview quickly mapped out, I asked where the first core step for this feature was. The team needed to identify where the first critical interaction happened on the timeline. The premise was that if people didn’t do this, everything else would fall apart. It was obvious that it was the point where participants indicated their interest in a course, and the coordinator was notified about this interest.
We took this small piece of the journey and ideated for the smallest and simplest solution the team could create to enable people as soon as possible to indicate their interest, without thinking about everything down the journey.
With this in mind, the team took a few minutes to write down as many approaches as possible in a short ideation session. After they had some options, the low-effort idea was to include a sentence and an email address in an existing prominent text field. Something in the regard of:
"Currently, there are no planned course times. To participate in the next one, please message course-coordinator@company.com."
This was an easy change. There was even no need for any custom code. And the team saw it as a great way to start learning about what would be needed. What are people writing in these emails? What open questions would coordinators have? And what does the whole process look like after some people indicate interest?
After this quick one-hour session, they presented the idea to the course coordinators. Even if they longed for an extensive solution, it was a winning reason to get a small solution in the coming days instead of waiting a few months. Additionally, the team promised to check in with them regularly and build upon what they learned.
This was a big win for the team. They solved part of the course coordination problem in less than a day, allowing them to concentrate on other issues while learning how much to invest in the future in this problem.
Why mapping is helping
As you saw, the team started by trying to build a big solution. After spending hours and hours in meetings discussing what needed to be built and how to build it, it would have been another big chunk in their backlog.
They could see the bigger picture and identify the most critical point by mapping their first thoughts and ideas. With this in front of them, they could step away from the big solution and ask critical questions about what is initially needed. They also gained awareness of the number of open questions without trying to answer them all without any more evidence.
Externalizing helps to simplify, reflect, and reassess. Relying only on verbal communication can make it easy to get lost in complexity and narrow paths. When we map visually, small solutions become more noticeable.