{"id":8466,"date":"2017-04-17T10:06:48","date_gmt":"2017-04-17T09:06:48","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=8466"},"modified":"2017-04-17T10:06:48","modified_gmt":"2017-04-17T09:06:48","slug":"not-make-product-feature-factory","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/not-make-product-feature-factory\/","title":{"rendered":"How NOT to Make Your Product a Feature\u00a0Factory"},"content":{"rendered":"

In each entry in this \u201cconversation\u201d series I talk to a designer\/product manager\/engineer on a topic. I want to make basic practical skills education transparent and free.<\/em><\/p>\n

Today I\u2019m talking to John Cutler<\/a>, Senior Product Manager at Zendesk<\/a>. John has written extensively on different product management topics and I love his views on product management and how it is evolving. In one of his most widely read Hacker Noon<\/a> posts, John discusses what he calls Feature Factories<\/em><\/a>. In this post we explore how to avoid the feature factory approach to product management.<\/p>\n

How would you describe a feature\u00a0factory?<\/h2>\n

\"A feature factory is a product or company that measures output over outcomes<\/strong>. It\u2019s a storypoint machine where the company only cares about is how much is being shipped. The company celebrates the work done and it feels like a conveyor belt going in one direction. No one is thinking about the question: is any of this really working!. No one is thinking if any of this complexity is adding business value.\"<\/span><\/p>\n

There is a fundamental difference between knowledge work and the manufacturing industry. Output cannot be measured in the same way. You have to get that experience right for the customers and focus on the right outcomes.<\/p>\n

<\/div>
<\/svg><\/div>

\"There are aspects of building a product which is challenging regardless of whether it has impact.\"<\/p><\/span><\/blockquote>\n

Some engineers can be motivated by a decently challenging technical problem. There are aspects of building a product which is challenging regardless of whether it has impact. For product people, if there isn\u2019t anything compelling about the product you can\u2019t do your job. You just check out or leave so the impact matters.<\/p>\n

What do you do to start focusing on outcomes and not\u00a0output?<\/h2>\n

\"We have to start by measuring product differently.Leadership can measure every other department pretty easily in the company like operations and sales by thinking about the bottomline of the business. With disciplines like product and UX it\u2019s much\u00a0harder.\"<\/span><\/p>\n

The next thing is to look at the problem and figure out how to create outcomes in that area. One thing I always say is if the product is not doing their job they are outsourcing product strategy to the rest of the company. Put the pieces of the puzzle together in a way which people can relate to and understand. Most people get that that product can be destroyed by unvalidated complexity. You have to figure out how to create a system of value delivery.<\/p>\n

Avoiding focusing on output also means that it\u2019s not that you are not working enough or working hard enough. It\u2019s that you are working more thoughtfully.<\/p>\n

Tip: One book I would recommend reading is <\/em>The Phoenix Project<\/em><\/a> which illustrates this well.<\/em><\/p>\n

Let\u2019s go through 10 ways in which we can do\u00a0this:<\/h1>\n

1. Measure the results and learn from\u00a0them:<\/h2>\n

Companies spend a huge amount of time making sure they are tracking every action of the user. The main problem I\u2019ve seen is not lack of access of data but they don\u2019t measure if any of the features actually work.<\/p>\n

<\/div>
<\/svg><\/div>

\"Differentiate measuring outcomes from measuring people and teams.\"<\/p><\/span><\/blockquote>\n

To start measuring the impact of releases it\u2019s also important for a company to have a learning mindset. You need trust in your organization to measure impact because there will be failure along the way and some releases may not work as intended. <\/p>\n

The learning aspect of measurement is also different than core level KPIs \u2014 it\u2019s how can we measure things to get better than just coming up with KPIs and OKRs. Differentiate measuring outcomes from measuring people and teams.<\/p>\n

It\u2019s also important to establish health metrics for the product to make sure user experience is maintained at all times as well.<\/p>\n

2. Storytelling and rituals make difference<\/h2>\n

One small way to create a product mindset around outcomes is to create small rituals around reflection. I did this in the form of precap design studio where when you kick off an initiative you give a presentation with blank numbers. And we would reflect on the before and after regularly once we ship it.<\/p>\n

<\/div>
<\/svg><\/div>

\"One small way to create a product mindset around outcomes is to create small rituals around reflection.\"<\/p><\/span><\/blockquote>\n

Having a ritual of reflection is thinking about the before and after. By doing this you get the team focused on the artefact. Every two weeks do a retrospective on the metrics. Doing a little over time is better than doing a whole lot at once and over committing.<\/p>\n

Another simple tactic is emailing out your metrics dashboard to the organization or sharing the retrospective meeting notes. These little things have an ability to become viral in an organization. Small rituals help build the habits.<\/span><\/p>\n

People usually over commit in terms of the methodology. Small companies invest massive resources to try and do some form of predictive analytics which takes at least an entire day to even report on. Start with what\u2019s sustainable and what you can keep up.<\/p>\n

3. Avoid shuffling of teams frequently and the project\u00a0culture<\/h2>\n

Some companies get the product and engineering people in a room quarterly, and have engineers self select the initiatives they want to work with.<\/p>\n

Sometimes shaking off teams can be advantageous but in this case the company gets obsessed with 150 things they have to do in the quarter and starts playing team tetris.<\/p>\n

<\/div>
<\/svg><\/div>

\"Product teams should be focused around a mission.\"<\/p><\/span><\/blockquote>\n

The release of a feature is just the start of it and teams should get the satisfaction of seeing it through. The moment you start calling features \u201cprojects\u201d then it signals that when it\u2019s released that\u2019s the end, when in most products it\u2019s just the beginning.<\/p>\n

4. Pay attention to how you celebrate product<\/h2>\n

Make sure you celebrate outcomes not just outputs. Some companies have demos where once in a week or two weeks the product team demos all the new features, which is the signal of being part of a feature factory.<\/p>\n

\"There is a huge impact of how you celebrate as a company. You can talk about different things like we talked to so many customers and what we\u2019ve learned, what happened with the feature we shipped and how the customers are reacting to it. Little words\u00a0matter.\"<\/span><\/p>\n

Support and marketing have the need to know what is being shipped \u2014 usually these shipping success theatres start when someone says \u201cI don\u2019t know what\u2019s coming out\u201d. That\u2019s a different problem than knowing if the stuff you ship is working. Be good to other teams and relay features but don\u2019t solve that problem by celebrating shipping only as a company.<\/p>\n

<\/div>
<\/svg><\/div>

\"Be good to other teams & relay features but don\u2019t solve that problem by celebrating shipping only as a company.\"<\/p><\/span><\/blockquote>\n

5. Iterate immediately after you ship to achieve better\u00a0outcomes<\/h2>\n

Some PMs tell engineers that improvements will come \u201clater\u201d and move on the moment the feature is shipped. Pulling a team to work immediately on something else and getting back to it after 6 months doesn\u2019t work in practice.<\/p>\n

<\/div>
<\/svg><\/div>

\"The best teams usually iterate to reach a better outcome.\"<\/p><\/span><\/blockquote>\n

Companies also don\u2019t acknowledge what the opportunity cost is. Sometimes teams take weeks to understand what the other team has built to iterate on it. One way to convince your company (assuming your dev team costs $50k per week) is to ask management if they\u2019ll be willing to spend $150k to come back to the item later. The best teams usually iterate on it to reach a better outcome.<\/p>\n

6. Get into the discipline of removing complexity and features which don\u2019t\u00a0work<\/h2>\n

One good exercise is to match customer value streams to areas of complexity. There will be areas of the product that have a large set of features but don\u2019t map to a lot of complexity. Killing features require multiple dialogues in organizations.<\/p>\n

Match customer value streams to areas of complexity. Once you start mapping your features to customer usage you can start digging into why and what you need to kill. In some cases you will see features being used for the way it\u2019s not intended\u00a0.<\/p>\n

7. Make sure PMs do retrospectives regularly<\/h2>\n
<\/div>
<\/svg><\/div>

\"Products are a series of decisions. Humans are terrible at talking about decisions retrospectively.\"<\/p><\/span><\/blockquote>\n

\"Usually product management meeting are about what we ship and status updates on ships that have sailed, they tend to be very reactive and there isn\u2019t really any time for reflection.\"<\/span><\/p>\n

No PM says they made a wrong decision a few months ago. It\u2019s important for product people in the company to get together and discuss how the craft can be better as a whole and reflect on the decisions they have taken.<\/p>\n

8. Get in the habit of iterating on features to achieve the right\u00a0outcomes<\/h2>\n

In feature factories product roadmaps have no room for iteration and it\u2019s all about shipping new features.<\/p>\n

\"The trick to get the company to think around iterating is to craft stories everyone can relate to around adoption. For example, you can say we have 1250 customers right now who meet the category for which a feature is valuable and right now 100 of them use it, so we want to focus on getting adoption\u00a0up.\"<\/span><\/p>\n

You should be able to make assumptions for your people who will be adopters. Say you are getting 500 beta testers on a new feature every week, one thing you can also say is that we will keep iterating with successive cohorts till we we get a high satisfaction score from most of them. Tie it to metrics and customers and tell a good story.<\/p>\n

Sometimes the people who get nervous with this approach are your engineering management who are highly incentivised by a feature factory and their measure of success is being responsive to product needs and keeping churn on the team low. They don\u2019t want to be blamed for being slow in any way. Usually what happens in that case is that engineers resign to the feature factory model and say we did our part and it was a poor product decision. This just drives more output and not good outcomes which are perverse incentives for engineers as well. <\/p>\n

<\/div>
<\/svg><\/div>

\"Make sure you align the iterations with good incentives for engineers as well.\"<\/p><\/span><\/blockquote>\n

Incentives are a difficult topic, but if people are incentivised for the fast completion of projects you will get a different culture than if teams are incentivised and rewarded for outcomes and learning.<\/p>\n

9. Don\u2019t just focus on reactive prioritization<\/h2>\n

All product managers focus on prioritization \u2014 in many cases it\u2019s the wrong type, it\u2019s reactive prioritization all the time. PMs are always stressed out with so many input channels and are trying to balance all of them to ship things and getting sign-offs from the company. Much of prioritization is about making educated guesses and making sure all stakeholders are happy (even if there is very little data backing it up). These guesses are important and it\u2019s good have a good set of heuristics but don\u2019t stop there.<\/strong><\/p>\n

Have conversations about the cost of delay<\/strong> \u2014 what will people pay to have a feature out today and not delay it. Have the conversation about whether is really worth it to us. Are we shipping value every sprint and by value it\u2019s not just shipping, it\u2019s learning and risk reduction as well. That\u2019s more important to focus on.<\/p>\n

<\/div>
<\/svg><\/div>

\"Force different types of conversation in the organization.\"<\/p><\/span><\/blockquote>\n

What people are missing is talking about if the product delivers continuous value and continuous learning. You want to bet on your horses when they are moving not before it and spending too much time on the reactive prioritization part.<\/p>\n

10. Avoid handoffs and tackle bottlenecks<\/h2>\n

In a lot of companies it\u2019s all about being more efficient and product management teams are outsourcing to other teams to get work done efficiently. So people start focusing on local maxima and not global maxima and managers end up playing team tetris. Customer feedback is a great example of a hand-off gone wrong. Your team ships a feature and you wait patiently for support to tell you when things have gone wrong.<\/p>\n

\"The culture of handoffs also means the culture of working around people. Instead of tackling bottlenecks you start working around them.\"<\/span><\/p>\n

The key to solve it is to visualize the system and show what steps things go through before it gets to the right people who can really act on it. Periodic reflection helps as well. To deliver 3x value from your product you have to make big shifts in the way you operate and chasing local maxima won\u2019t do it.<\/p>\n

Finally John, what\u2019s your product management process?<\/h2>\n

I don\u2019t use scrum and don\u2019t do story points. It\u2019s important to ask oneself why are we hiring the tools we are using and then use them. Scrum in a toxic and non trusting environment just becomes more toxic. If scrum is a good template for you go ahead and use it. But if people say they want to use scrum to just measure velocity or holding engineers accountable you want to ask why.<\/p>\n

For example, we are good at writing stories and decomposing problems in general we take 3\u20135 days for every story so you can easily calculate velocity, we don\u2019t need scrum for that.<\/p>\n

<\/div>
<\/svg><\/div>

\"Know the limitations of the tools you are using.\"<\/p><\/span><\/blockquote>\n

We use JIRA but it has it\u2019s limitations, it\u2019s built on the philosophy that there is only one owner so you start to develop a shadow economy if engineers need help from each other. Know the limitations of the tools you are using. Kanban is an amazing visualization tool which I like.<\/p>\n

The more important question to focus on is what\u2019s the outcome and are we delivering continuous value every sprint which is what we try to do.<\/p>\n

This article was originally published on Romy's Medium Page<\/a>.<\/em> <\/p>\n

Cross publishing this from <\/em>Hacker Noon<\/em><\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

In each entry in this \u201cconversation\u201d series I talk to a designer\/product manager\/engineer on a topic. I want to make basic practical skills education transparent and free. Today I\u2019m talking to John Cutler, Senior Product Manager at Zendesk. John has written extensively on different product management topics and I love his views on product management and how it is evolving…. Read More ￫<\/a><\/p>\n","protected":false},"author":118,"featured_media":8472,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-8466","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-viewpoint"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n