More ≠ Better, a framework for feature decisions

BS Mission Statements

Say "mission statement" to a group of tech people and you'll hear a lot of sighs. Does it make you think of corporate buzzwords and executives that talk the talk but don't walk the walk?

Regardless of what you call it, it's vital for a new startup to have a mission or north star that actually means something to the founders.

North Star

Products and companies evolve. Suggestions flood in from users, customers, friends. Data starts to show trends. Founders start to see what's working and what's not.

A big problem at startups is how to choose what feature they're going to add next. Many startups end up adding features that were in their backlog and no one stops to think "but why should we do this? is it aligned with the mission? is there data to support it?".

Seagull Corp.

Let's say a founder at Seagull Corp. wants to test out an idea so they go ahead and add Feature X.  In 6 months, 90% of users don't use that feature because it's not really something they care about. The 10% of users that do use it report a lot of bugs. There are 12 low priority bugs in the backlog for Feature X.

Feature Y is the crowning jewel of the app. Most users that use that app love it and it's a key reason why they keep coming back to the app. There are no bugs in the backlog for this feature because they're always high priority and get fixed immediately.

The reality is this:

• Most founders will leave Feature X in forever, support it, and feel guilty about the unfixed bugs and complaints from users that use it (and about stringing them along about when they'll be fixed). They figure more features is better. The bugs stay in the backlog forever and are never done.
• If the founder stopped to consider whether they should delete Feature X altogether, how would they even evaluate it? We know only 10% of users use it--is that enough to axe it?

Having a north star helps every single person on a startup team make decisions. The north star influences all work done and subconsciously influences the tiny micro-decisions that teammates make while they're working, whether they're coding, writing marketing copy, or helping customers.

Let's deep dive on Feature X and Feature Y.

Seagull Corp.'s north star is to help teachers spend more time teaching and less time doing admin.

Feature Y

Feature Y is a to do list planning app that delivers a small prompt to the teacher via email each week in summer to help them plan the next year without feeling overwhelmed.

• Week 10 prompt: Let's think about lesson plans for module 3. Last year, you used the below 12 lesson plans. Other CA teachers have reported that due to curriculum changes you should swap out the last one with the 2023 version. Do you want to accept these suggestions as draft for Module 3?

This feature is beloved by teachers. It's directly contributing to the North Star--it saves admin time and helps them make slow, measured progress towards the next school year. The data shows that it's sticky and useful.

There's no question that feature Y is staying for now. Easy decision.

Feature X

Feature X let's teachers design one-off custom lesson plans for students that are having trouble learning a concept. It sounds like a good idea that could help students that are struggling.

Feature X is the sexy beast that the founder came up with in a fever dream. It's complicated and kinda cool, but it's super time consuming for teachers to use since they have to spend 15 minutes customizing it for each student. It adds too much time--they could have spent the 15 minutes working with them directly instead of preparing the custom plan and then working with them on that.

Teachers found it clunky to use, buggy, and not really solving their problem so they don't look at it much. The 10% of users that are using it are trying it out for the 1st or 2nd time and usually don't come back a third.

• This feature causes teachers to spend more time on admin. It's directly against the north star of Seagull corp.

Proposed Framework

So how should founders think about adding and getting rid of features?

Adding Features

1. Designate a decision-maker. This could be the founder, product person, or whoever. Give someone the agency to decide.
2. Collect feedback on features from users, data, word of mouth, online reviews, employees, and wherever else you can.
3. Write down context--where this feature idea came from, what problem it's trying to solve, any factors that exist, how many times did customer support log the request, etc (cost, time to code, etc).
4. Write down open items that you would like feedback on in a short, concise list.
5. Get feedback on the feature and open items from stakeholders, users, whoever you think is relevant.
6. Let the decision-maker decide.
7. If you decide to do it, write down the following: how it's contributing to the company's north star, what assumptions are being made, what success would look like for this feature, what might change depending on coding strategy, and whatever other context you have. If you decide not to do it, write that down too for next time this comes up.
8. Now the feature is ready to be scoped and fleshed out by a product person. Once the feature is live, schedule a time to review it's performance. If it never gets to "live", consider why it's being snoozed repeatedly and evaluate whether you should send it to live in icebox for now.

Getting Rid of Features

1. Set up a calendar invite to review all features and performance. If your startup is a little more established (2-3 years old), it makes sense to do this less often (e.g. quarterly). If your startup is a tiny and searching for product market fit, you should consider doing it more often (e.g. ~1x/month).
2. Collect feedback on features from users, data, word of mouth, online reviews, employees, and wherever else you can.
3. Review your reasoning for adding the features and the feedback.
4. Make an executive decision and record the reasoning behind the decision.