New Approach To Product Development

These days, it looks like everyone is developing a technology product. While we’re developing them, we think of a set of features to build that would maximize business value and also solve customer’s problems.

But how does a team prioritize features?

Today’s current development process mostly has a product head (entrepreneur, head of product) that discusses features to build with the development team and places them accordingly in a backlog, icebox or in the current feature set to be built. The process is individualistic and mostly driven by someone who has a holistic view of the entire business.

But is it possible the priority list set by a product head can be wrong?

Is there a way to democratize the product development process?

Is there a way to quantify the impact of the feature built on the business?

How do we decide to go after low hanging fruit or build features that will transform the product completely?

In my recent interactions with startups, I have started sharing a new form of prioritizing features to be built that could be helpful in the product development process. It's called Impact versus Technical Ease and here is a quick snapshot.

Impact versus Technical Ease

This tabulation consists of 8 major columns or data points: Topic, Action Items, Metric, Impact, Technical Ease, Priority and How to Test It & Owner.

1. Topic

The topic is usually a 8–10 word summary of the feature/enhancement that we want to build.

For example: Referral system for drivers.

Think of it as a heading that describes the feature to be built. With a quick glimpse, you should be able to decipher the action item we are referring to.

2. Action Item

The action item is very similar to suggesting a feature you want to build or a problem that you want to solve.

It’s usually 30–45 words and is in the format of: As ‘X’ I would like to do ‘Y’ so that ‘Z’.

Example: As a marketer, I would like to find a way to incentivize drivers to refer other drivers to the platform so that we can increase the number of drivers on our platform.

3. Metric

One of the additions to this product development process is adding a metric. Each action item should be associated with the metric it’s impacting.

From a growth hacking standpoint, we should refer to the 5 metrics:

  • Acquisition
  • Activation
  • Retention
  • Referral
  • Revenue

As much as each feature is revenue driven, it’s important to associate each feature with one of these 5 metrics.

Most product development tools like Pivotal Tracker allow tags for each feature. You could tag each of the features with this metric.

4. Impact

One of the most important part of this process is to quantify impact as well as democratize it. This consists of deciding the feature’s impact on a scale of 1–10. 1 being lowest impact and 10 being of highest impact it has to the business.

Remember, if building a feature can reduce an employee’s time in manually delivering a service, it could supercede a feature that solves a customer’s problem. Because freeing up an employee’s time can help him/her focus on high value activities.

We also introduce is 2–3 decision makers in this process. Not just one person. The new people involved can be marketers, growth hackers, COO’s i.e. people who have a holistic understanding of the business. Each of them will place a rating between 1–10 and the average of the rating should be calculated under the average column.

However, if you still feel the product manager should have a big say in the prioritization process, we give more weighting to his rating. So, the weighting instead of being split 3 ways as 33%, 33%, 33% can be split as 50%, 25%, 25% with 50% being associated with the product head.

5. Technical Ease

Just like how we quantified impact, we should quantify technical ease as well.

We place technical ease on a scale of 1–10, with 1 being hardest to build/highest implementation time and 10 being easiest to build/lowest implementation time. We place a rating between 1–10 for each of the features.

We introduce 2–3 technical experts within the team (CTO, Stack developers) in this process and ask each of them to place a score. After that, we calculate the average of technical ease for that feature. Similar to the impact column, we can give higher weighting to a certain decision maker like a CTO or a Tech Lead.

6. Priority

Priority is calculated as Avg. of Impact x Avg. of Technical Ease.

The product of the two would provide an answer on a scale of 100 which can be reduced to a scale of 10. Now, features that can be quickly built and have highest impact on business will be pushed up the product development process while features that are of low impact and involve high technical debt would be lower in the order.

Once we have the list of features to be built, with impact and technical ease columns filled out, we arrange the priority column in descending order.

7. How Do We Test It

In small teams (8–15 people), everyone should be responsible for growth and implementation if possible.

Once we have a priority list of enhancements to be built, there should be a way to build the simplest MVP possible or test this without the usage of technical debt.

If so, someone within the team takes ownership to test or build it.

8. Owner

The last column is the owner of this feature. As a team we decide who would own this feature to implement it. It could have up to 3 owners depending on the individuals involved.

Smaller teams that are lean and agile can benefit a lot from implementing these techniques in their product development process. Either teams can integrate these techniques in the tools (Pivotal Tracker, Trello, Asana) they use or use simple google docs to decide priorities.

The template is available here.

15 Things To Do And Go From Idea → Product Market Fit → Scale

Cover Image: Code | Michael Himbeault