How to Start Features [5/100]

I’m writing 100 posts about product development and product management. For this challenge I take weekly cadence, so you can expect a new post every week (or less). This is post #5.

Every product manager loves new features. She loves to define problems, invent solutions and push them into development. This process is not as simple as it might look. Let’s dive into it and explore some best practices.

Don’t start a feature 🛌

By default, new features should not be started. Every feature should be justified by real evidence and/or the product manager’s vision. It’s helpful to ask several questions before any serious effort:

• Can our users live without this feature?
• How painful to not have this feature for users?
• Is this feature aligned with our strategy?
• Do we have any viable workaround?

It might happen that the problem you are going to dig into is not that important, or there is a good workaround in a product, or it deviates from the product strategy.

Check yourself for Recency bias. There is a good chance that the feature was requested by 1-2 customers last week, but was never requested for months before that. Recency bias is hard to avoid. The only solution is to collect real evidence and back feature importance by customers feedback.

Collect evidence 🕵️‍♀️

It is super helpful to collect problems, solutions, and link real feedback from the end-users to these problems and solutions. Eventually, top problems will become obvious and your decision-making process will be much easier.

For example, you have a choice to solve two problems: one is about creating private documents, another is about custom emoji. Evidence for the last 6 months shows that private documents were mentioned 55 times, while emoji only 4. It is not that hard to set priorities now.

You may still decide to go for emoji as an exciter feature, but this is your deliberate choice backed by data. Otherwise, it’s just your gut feeling. I should say that in many cases gut feelings work well, but real evidence is still better.

You decided to go for it and start the Private Documents feature. The problem is clear, users want to create private docs. Or is it? What exactly do they want? Maybe create private folders as well? Maybe create private views? If you collect feedback, you might find the most popular cases. If not, you will have to contact your users and ask.

Explore existing solutions on the market 🎣

In 90% of cases, your problem was solved somehow in other tools. It is always good to steal good ideas, but you should do it with style. Where to look? Let’s say, you are working on Product Management Software, and Private Docs feature is related to this market.

• Check your competitors, maybe they had a similar problem and solved it. Check Aha!, Product Board, etc.
• Check other markets where you think this problem could have happened. It’s likely that in Wiki tools this problem is solved.
• Google it (Images!). You might find the solution in a surprising place.

What is the process here? I recommend the following steps:

1. Try to think deeply about the solution in every tool. Why do they do it this way? Is it pleasant to use?
2. Spot small interesting details. They will help you to generate new ideas and make the final solution better. For example, private docs might have a special icon. Good detail to know!
3. Collect all solutions in a single document (screenshots + your observations and notes), link it to the feature.

Invent and document a solution 🎰

You have users’ feedback, you defined the problem, you checked existing solutions. Now you are ready to invent your own solution. This process is very individual. The general flow is to think, draw, write, repeat. You can do it alone, you can do it as a team. Latter is better, it is also more time-consuming. Many practices help with the creative process, but I will not dig into it there.

The final result is a solution that can be easily comprehended by other people. Usually, it is just linear text + images/sketches/diagrams. In some more complex cases, it might be a live prototype. The main goal is comprehensibility. Any teammates should be able to understand how it should work.

I prefer to use the Problems/Solutions template for my features. It helps teammates to focus on the problems first. It might happen that problem is not correct or have a completely different better solution. Problem/Solution structure helps to discover such cases.

Sometimes I describe several alternative solutions and state my preferences. Sometimes I describe the path to the solution to help teammates understand it better.

BTW, in this particular case we decided to have a solution similar to Notion — a special “My Space” section in the left menu where a user can create her own private items (documents, views, folders).

Run a Feature Kick-start Meeting 🤼‍♂️

When the solution is documented and discussed async, it is time to have a formal feature kick-start. I like to have a sync meeting for that. Feature Kick-start meeting is a sync communication to discover missing requirements, briefly discuss technical challenges and nail some plans. It includes 1-2 developers that will implement the feature, QA engineer, and Product Owner. Other people can join to participate/listen if they want.

What should be discussed?

In general, these areas should be discussed:

• What functional requirements are missing? What is not clear enough? Can we reduce feature scope and move some requirements into future features? Can we not implement the feature at all?
• Do we have technical limitations? How do they affect functional requirements? Do we have a clear path of technical implementation?
• Can we provide rough estimates? Do we need to clarify things?

Kick-start meeting results

• All participants are aligned and understand why the feature is important, and how it should work.
• List of missing requirements that should be added
• List of functional spec corrections (in most cases they are added during the meeting)
• Feature planned dates (or a decision to do a Spike)

A product manager has some work to do after the meeting: add missing requirements, clarify some details, split feature to smaller features. When it is done, feature can be taken into development.

---

As you see, many things should be done to really start the feature. And when the feature is started, you should complete it.