But how?

The clue to his success in my opinion is his single-mindedness. He’s 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, 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’t align to his end goal; he put his relationship with his cousin above his main objective, which ultimately cost him his life.

The point I’m 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 – be it a new feature for an existing product, or the first, shiny new website for your company that’s 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 – and ultimately reduce the potential return on investment from your outlay.

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

Software development is exactly the same. If you’re 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’re trying to solve, and what is the reason we’re 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.

A traditional New Jersey standup.

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’ll greatly reduce his ability to earn. So the options available to him when boiled down to this level are simple ones;

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

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.

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 – does fixing the bug takes us a step closer to solving the problem, or will it have no impact on the problem we’re trying to solve? If you don’t know the answer to these questions, you don’t 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.

Another important benefit when defining your problem statement and the goal you’re trying to achieve up front is the fact that you can ensure that whatever the end result is, it’s measurable. 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. If we know that currently, 90% of customers don’t 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 – and this means our productive output is quantifiable in terms of value. If we don’t 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.

Measuring success. In this instance, the measure is how many oil paintings of yourself you own.

The same is true for any digital project, not just for new features, but entire product builds – 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’re 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 ‘contact us’ 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.

If we’re 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’ve already put things in their basket and we want them to finish the sale, then it’s a matter of making that process as simple as possible; elaborate design isn’t necessarily the answer. And again, if we ensure that the end result can be tracked and analysed in terms of stats, then we’ve ensured that we have a basis in fact to inform any subsequent decisions as we move forward with continuous improvement – we can quantify everything we’re doing, measure the outcome, and determine whether the decision was the right one – 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.

This value proposition also allows us to define our MVP – we know we could build everything, with unlimited time, money and budget, but do we really need to? These decisions become easier when we’re aware of what the point is – 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’re unsure we’re 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?

The ducks in this image are the metaphorical MVP. Deep.

Ultimately, when you’re looking at investing time, money and effort into a new digital endeavour, keep thinking ‘What would Tony Soprano do?’ – because if you can align the project and everything it involves back to your problem statement, you’ll find those difficult decisions a lot easier down the line.