{"id":109,"date":"2015-05-30T13:51:16","date_gmt":"2015-05-30T12:51:16","guid":{"rendered":"http:\/\/www.scrummable.com\/?p=109"},"modified":"2017-06-16T10:49:28","modified_gmt":"2017-06-16T09:49:28","slug":"making-like-a-mob-boss-knowing-your-problem-and-how-to-fix-it-2","status":"publish","type":"post","link":"http:\/\/scrummable.com\/making-like-a-mob-boss-knowing-your-problem-and-how-to-fix-it-2\/","title":{"rendered":"Making like a mob boss: knowing your problem and how to fix it"},"content":{"rendered":"

Tony Soprano is a badass. He\u2019s the epitome of power, charm, ‘New Joy-sey’ mafioso cool. Under his leadership, the New Jersey family grew in power to the point that it reckoned with the New York mob, which (irrespective of divided opinion on what really happened at the end of season 6) is a pretty impressive accomplishment in anyone\u2019s book.<\/div>\n

But how?<\/p>\n

The clue to his success in my opinion is his single-mindedness. He\u2019s goal-orientated and entirely driven by one single objective: making money. His most successful endeavours on the show over 7 years arose from his dedication to one main objective, and his biggest mistakes (Ralphie<\/em>, anyone?) occurred when his interests were elsewhere. Arguably (not that I want to admit that he died at the end of season 6), the ultimate decision that cost him his life was one that didn\u2019t align to his end goal; he put his relationship with his cousin above his main objective, which ultimately cost him his life.<\/p>\n

The point I\u2019m trying to make here is that Tony Soprano would make a damn fine product owner. This sort of single-minded determination is absolutely key when approaching any sort of software build \u2013 be it a new feature for an existing product, or the first, shiny new website for your company that\u2019s sorely lacking a digital footprint. All too often, software or web design projects are undertaken without simple, up-front analysis of the end-goal. And skipping this step in the planning process can massively decrease the effectiveness, and success, of the end result \u2013 and ultimately reduce the potential return on investment from your outlay.<\/p>\n

Take Tony. Tony has one goal: making money. Every decision he makes throughout the series is ultimately driven by this one, fundamental objective \u2013 and every option is weighed up in terms of the risks vs. the potential reward\u00a0in relation to his end goal. If the return is worth it, then risk be damned. If the return isn’t worth it, then it\u2019s parked until a less risky alternative presents itself.<\/p>\n

Software development is exactly the same. If you\u2019re building a feature, then the first thing you need to work out, before you even start discussing what the feature is, is the end goal. What is the problem we\u2019re trying to solve, and what is the reason we\u2019re solving it in the first place? Defining the answers to these questions at the beginning of the project, learning them by heart, writing them in 3 foot tall letters on the wall of the meeting room where all your planning sessions take place, and reciting them like a mantra at the beginning of every standup is good practice; it keeps everybody focused on the point, and it allows the decision making process down the line to be much, much easier.<\/p>\n

\"\"

A traditional New Jersey standup.<\/p><\/div><\/p>\n

Take Tony for example: he has the opportunity to become head of the family when Jackie Aprille dies, but he chooses to let Junior take the job. Why? Because the FBI attention if he became boss would be a hindrance; and if he ends up in prison, he\u2019ll greatly reduce his ability to earn. So the options available to him when boiled down to this level are simple ones;<\/p>\n

    \n
  • Take the position and potentially reduce your earning power when\/if you get caught.<\/li>\n
  • Let Junior take the job, \u00a0keep the focus off yourself, and continue to make the decisions and increase your potential income.<\/li>\n<\/ul>\n

    Even though there are a few steps in the process before ultimately getting back to the bottom line here, the eventual outcome remains aligned to the end goal. And that means the decision is the most appropriate one, as it’s based entirely on what you’re trying to achieve.<\/p>\n

    Likewise with software: take a bug found 2 weeks into a 4 week project. This bug, after analysis, may defer the release of your new feature or website by an additional 2 weeks if you fix it. But it can just as easily be left as it is and fixed at a later date, with little impact to your ultimate objective. Deciding whether you fix the bug now, or later, is easy if you have the end goal defined up front \u2013 does fixing the bug takes us a step closer to solving the problem, or will it have no impact on the problem we\u2019re trying to solve? If you don\u2019t know the answer to these questions, you don\u2019t have a baseline for which to weigh up and compare cost-benefit down the line, once the project is underway and those inevitable bumps in the road emerge.<\/p>\n

    Another important benefit when defining your problem statement and the goal you\u2019re trying to achieve up front is the fact that you can ensure that whatever the end result is, it\u2019s measurable<\/b>. Your problem might be that customers are not able to find the FAQs page on your website for example (which means you’re receiving increased calls to your support desk). If you decide that you can solve this problem by dropping a prominent call to action on every page within the site that directs people to FAQs, then you can easily establish the KPIs which determine if your new feature has been a success.\u00a0If we know that currently, 90% of customers don\u2019t go to the FAQs page before calling the helpdesk, then we can establish that a drop of 15% to this figure might be a success \u2013 and this means our productive output is quantifiable in terms of value.\u00a0If we don\u2019t have the ability to measure whether the feature is a success at the moment (other than less complaints from the support team), then we can potentially look at including some statistic tracking or analytics as part of the feature build, to start measuring the work from the point of release.<\/p>\n

    \"\"

    Measuring success. In this instance, the measure is how many oil paintings of yourself you own.<\/p><\/div><\/p>\n

    The same is true for any digital project, not just for new features, but entire product builds \u2013 establishing the point up front can inform all of the decisions along the way, from design, to tone, copy, audience, required functionality, and development approach. If we know we\u2019re building a brochure website whose purpose is to offer a simple digital presence and provide an easy means to find out where your offices are, and how to get in touch, then the emphasis may be high on design, low on content, simple in terms of functionality but heavy on calls to action and drive to the \u2018contact us\u2019 section. We also know that we may want to invest time in implementing analytics and tracking, so we can quantify the success of our brochure website and continuously make improvements to increase the conversion rate between visit and contact.<\/p>\n

    If we\u2019re building a new checkout process into an existing e-commerce website to ensure that drop-offs and abandoned basket rates decrease, then we know that usability is paramount. We also know that copy throughout the process (although used sparingly) can be key in providing an indication of how the process works to the customer. We know that functionality is more important than form here, because the end goal ultimately is to get more people completing a transaction. If they\u2019ve already put things in their basket and we want them to finish the sale, then it\u2019s a matter of making that process as simple as possible; elaborate design isn\u2019t necessarily the answer. And again, if we ensure that the end result can be tracked and analysed in terms of stats, then we\u2019ve ensured that we have a basis in fact to inform any subsequent decisions as we move forward with continuous improvement \u2013 we can quantify everything we\u2019re doing, measure the outcome, and determine whether the decision was the right one \u2013 and arguably more importantly, we can attempt to learn why that decision wasn’t the right one if it doesn’t achieve it’s original objective.<\/p>\n

    This value proposition also allows us to define our MVP \u2013 we know we could build everything, with unlimited time, money and budget, but do we really need to? These decisions become easier when we\u2019re aware of what the point is \u2013 and also inform decisions about the technical approach we take. If this is simple, do we need to adopt the latest bleeding edge tech, or are we safe with implementing something off the shelf? If we\u2019re unsure we\u2019re going to fix the problem, do we perhaps want to invest some time in A\/B testing, to allow us to measure the success of multiple approaches to solving a problem?<\/p>\n

    \"\"

    The ducks in this image are the metaphorical MVP. Deep.<\/p><\/div><\/p>\n

    Ultimately, when you\u2019re looking at investing time, money and effort into a new digital endeavour, keep thinking \u2018What would Tony Soprano do?\u2019 \u2013 because if you can align the project and everything it involves back to your problem statement, you\u2019ll find those difficult decisions a lot easier down the line.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Tony Soprano is a badass. He\u2019s the epitome of power, charm, ‘New Joy-sey’ mafioso cool. Under his leadership, the New Jersey family grew in power to the point that it reckoned with the New York mob, which (irrespective of divided opinion on what really happened at the end of season 6) is a pretty impressive […]<\/p>\n","protected":false},"author":4,"featured_media":575,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5,6,7],"tags":[],"_links":{"self":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/109"}],"collection":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/comments?post=109"}],"version-history":[{"count":0,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/109\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media\/575"}],"wp:attachment":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media?parent=109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/categories?post=109"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/tags?post=109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}