{"id":779320,"date":"2021-11-30T10:02:09","date_gmt":"2021-11-30T18:02:09","guid":{"rendered":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/?post_type=msr-blog-post&p=779320"},"modified":"2021-11-30T10:07:25","modified_gmt":"2021-11-30T18:07:25","slug":"why-and-how-to-test-your-ideas-to-ensure-success","status":"publish","type":"msr-blog-post","link":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/articles\/why-and-how-to-test-your-ideas-to-ensure-success\/","title":{"rendered":"Why and how to test your ideas to ensure success"},"content":{"rendered":"

By John Westworth (opens in new tab)<\/span><\/a><\/p>\n

\"people<\/p>\n

Image credit: iStock\u00a0<\/em><\/p>\n

In part one of this blog post<\/a>, we introduced the concept that most new ideas, features, or products are destined to fail, and why. We\u2019re going to continue on those thoughts with more reasons why, and how to mitigate them:<\/p>\n

You\u2019ve over engineered the solution:<\/strong>
\nThe Roundabout PlayPump was initially met with excitement when it was announced \u2013 It was a merry go round that pumped water. The premise was that while the children were playing, they\u2019d also be pumping water. However, the reality was different. It was too complex to maintain and difficult to repair, especially in the environments in Africa where it was being installed. A simple hand pump was far cheaper to install and a lot easier to fix if it stopped working.<\/p>\n

While this is an extreme example, there are many examples where solution technically solved a problem but the trade offs didn\u2019t make sense. They just ended up being too complex to use and to support.<\/p>\n

Ask yourself and your team \u2013 \u201cWhat\u2019s the simplest way we can solve this problem?\u201d<\/p>\n

You listened to the Hippo<\/strong>
\nHippo \u2013 Highest paid person in the Office. They\u2019ve just read the latest buzzing business book, met one of their most vocal customers, are desperate to find ways to hit a metric that\u2019s been imposed on them or just had a brainwave over the weekend. Either way they\u2019ve got a brand new idea that\u2019s got to be implemented.<\/p>\n

It\u2019s amazing how the necessity for being data-driven or data-informed can just get thrown out the window depending on the authority of whose idea it is. But this is is incredibly dangerous, In his paper \u201cPower and Perspectives Not Taken\u201d Aadam Galinsky notes that people with power find it more difficult to take someone elses perspective. Which means that their idea, while great to them, may not be so good for your users and customers.<\/p>\n

Which leaves you in a bit of a pickle \u2013 how do you tell the emperor he has no clothes?<\/p>\n

Either bring data, suggest additional research or testing the idea with customers or just go back to your companies or products mission statement. At Microsoft an easy question to ask is \u201cHow does this idea help our customers or users achieve more?\u201d But please, don\u2019t just go and implement it.<\/p>\n

You\u2019re solving a symptom, not the problem<\/strong>
\nTaking Ibuprofen may treat your toothache, but the underlying problem may be that you not taking care of your teeth as well as you should.<\/p>\n

You can keep pumping are into your tire, but unless you fix the puncture it\u2019s going to keep going flat.<\/p>\n

And you can keep trying to solve the immediate problem of your users, without looking at the context, systems and incentives that are in place.<\/p>\n

While you may treat the symptom may make the immediate issues, the root cause may still remain \u2013 and actually be getting worse if left untreated.<\/p>\n

Use the 5 Whys (opens in new tab)<\/span><\/a> to try and get to the root cause of the issue. Keep digging \u2013 you may be surprised at what you uncover.<\/p>\n

You looked at the problem in isolation<\/strong>
\nMost problems aren\u2019t caused by people in isolation \u2013 they\u2019re caused by the context, environment, systems they inhabit and the way they\u2019re incentivized.<\/p>\n

If we just solve their problem in isolation we may cause further issues upstream or downstream of where the work that they\u2019re doing.<\/p>\n

For example, you may incentivize someone to do A and in the process they neglect B, C and D.<\/p>\n

Map out your customer\u2019s entire journey, not just the specific problem you\u2019re looking at. Ask them what happens immediately before and after to get a sense of the context of the issue.<\/p>\n

You solved one problem but created others<\/strong>
\nWe\u2019ve now democratized reduced the friction of creating presentations and holding meetings and democratized it. Now everyone can create fancy presentations and hold a meeting at moment\u2019s notice. Hooray.<\/p>\n

But wait a minute \u2013 The premise is that most presentations and meetings are good, therefore we should have more of them and invite more people.<\/p>\n

But what if that premise is wrong? What if most presentations and meetings aren\u2019t so good? What if making it easier and having more of them isn\u2019t such a good idea? What if we\u2019ve now made it easier for people to waste other people\u2019s time?<\/p>\n

Doing a premortem of your idea and taking on different roles is a great way of thinking through the unintended consequences of implementing your idea.<\/p>\n

You\u2019re solving your employer\u2019s problem and rationalizing it as a customer problem<\/strong>
\nWe humans are great at coming up with ideas then retrofitting the justification later. I bought this Tesla because it\u2019s economical and good for the environment, definitely not because I wanted to have a cool car.<\/p>\n

Sometimes a focus on our company\u2019s strategy will make us come up with ideas that we then justify as being pro-user. A common example of this is having usage as your KPI or OKR or whatever the latest term you’re using for Goodhartesque(2) target is.<\/p>\n

While you may hit the target, you may miss the point \u2013 Yes, forcing your users to use your product will drive metric X but will also increase resentment and disdain.<\/p>\n

While company strategy is important, we need to balance this against customer outcomes.<\/p>\n

You\u2019re looking at the problem through the lens of your product or role<\/strong>
\nSales of your product are down \u2013 Depending on your role it\u2019s a research, design, development, sales or marketing problem. In reality, it\u2019s probably more nuanced than that. It\u2019s usually a combination of all of these. What tends to happen is instead of coming together to solve the issue each role will go away, look at it through the lens of their role , and try and solve the problem in isolation.<\/p>\n

A similar thing happens if you have a portfolio of products. Each team will look at the same problem, in isolation, through the lens of their product. This leads to disjointed products, duplication of features, incomplete solutions and confusions for users.<\/p>\n

Take a step back and get different perspectives on the issue. You\u2019ll get a different, more coherent way of looking at the issue.<\/p>\n

We need to take a good hard look at the problems we\u2019re solving before we get into solutioning. Yes, coming up with solutions is the interesting and exciting piece but once you\u2019re on this path it\u2019s very hard to turn back. We fall in love with our idea, we fall for the sunk cost fallacy, we believe that A\/B testing will fix the problem.<\/p>\n

So yes, your solution may be incredibly innovative and completely cool \u2013 but does it make life better for the user? Is that increase worth the cost (both initial and lifecycle)?<\/p>\n

No doubt you view your project differently \u2013 \u201cof course there\u2019s a market need for it\u201d I hear you cry. Your confidence may be sky high because of one or more of the following:
\n\u2022 A customer asked for it.
\n\u2022 A competitor has it
\n\u2022 You ran a focus group and people loved it.<\/p>\n

But beware \u2013 I can guarantee that someone on the team can use those very same reasons to justify their idea.<\/p>\n

So before jumping to a solution, take some time to check you understand the problem. You\u2019ll save yourself, your company and your customers time and money.<\/p>\n

What do you think? How can these ideas help you design better products? Tweet us your thoughts at @MicrosoftRI or\u00a0follow us on Facebook (opens in new tab)<\/span><\/a>\u00a0and join the conversation.<\/strong><\/strong><\/p>\n

John Westworth is a Design Researcher in the Office Design and Research team. He is passionate about providing leadership to help companies implement change and manage transformation to use new technologies that impact how they work. Check out John\u2019s other blog articles, \u201cA responsible approach to innovation,”<\/a> “Conflict: The missing ingredient and biggest test of a growth mindset,” <\/a>and “The true cost of your idea<\/a>.“<\/a><\/em><\/p>\n

(2) Goodhart\u2019s law \u2013 \u201cWhen a measure becomes a target, it ceases to be a good measure\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"

We need to take a good hard look at the problems we\u2019re solving before we get into solutioning. Yes, coming up with solutions is the interesting and exciting piece but once you\u2019re on this path it\u2019s very hard to turn back.
\nSo yes, your solution may be incredibly innovative and completely cool \u2013 but does it make life better for the user? Is that increase worth the cost (both initial and lifecycle)?<\/p>\n","protected":false},"author":38703,"featured_media":779335,"template":"","meta":{"msr-url-field":"","msr-podcast-episode":"","msrModifiedDate":"","msrModifiedDateEnabled":false,"ep_exclude_from_search":false,"_classifai_error":"","msr-content-parent":616842,"msr_hide_image_in_river":0,"footnotes":""},"research-area":[],"msr-locale":[268875],"msr-post-option":[],"class_list":["post-779320","msr-blog-post","type-msr-blog-post","status-publish","has-post-thumbnail","hentry","msr-locale-en_us"],"msr_assoc_parent":{"id":616842,"type":"group"},"_links":{"self":[{"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post\/779320","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post"}],"about":[{"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/types\/msr-blog-post"}],"author":[{"embeddable":true,"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/users\/38703"}],"version-history":[{"count":3,"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post\/779320\/revisions"}],"predecessor-version":[{"id":800836,"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/msr-blog-post\/779320\/revisions\/800836"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/media\/779335"}],"wp:attachment":[{"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/media?parent=779320"}],"wp:term":[{"taxonomy":"msr-research-area","embeddable":true,"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/research-area?post=779320"},{"taxonomy":"msr-locale","embeddable":true,"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/msr-locale?post=779320"},{"taxonomy":"msr-post-option","embeddable":true,"href":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/wp-json\/wp\/v2\/msr-post-option?post=779320"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}