It's easy to get distracted by unnecessary detail and elaboration in our day to day working lives and lose focus on the problem that we're trying to solve, and why we're trying to solve it. Hence, concentrating on the "Outside In" perspective is a great tool to use to keep focus. "Outside In" is not a new term, it's all about building a customer centric business, whoever your customer is - internal or external.
This "Outside In" view will often differ from the "Inside Out" view and there's value in applying this principle, but what exactly do we mean by Outside In? Here are a few examples to explain what it means to me.
If you're a CTO or IT Director, how are your systems positioned to your users? Is the focus on promotion of features and functionality, i.e. an “Inside Out” view; or is the focus on the specific business problems the system is addressing along with details of the features that help alleviate them, i.e. an “Outside In” view. As an end user, the more compelling story is the one that focuses on what a system does to provide solutions to specific problems rather than one that emphasises the functionality specific view.
Taking the example of an Engineering team, you might have a team that builds something technically superior and elegant with a large percentage of the solution being used rarely if at all or making no difference to the end user in terms of functionality or experience.
Taking an "Outside In" perspective allows us to focus on delivering products that provide benefit to customers without the need for technical elegance or enhanced functionality that may not be utilised in a real-life use scenario.
Let's say I'm responsible for the roll out of a new implementation of a software product that is made up of various processes to support my business and integrations with multiple software products. I need to run user acceptance testing (UAT) for the product, which could potentially run into thousands of test cases.
If I adopt an "Inside Out" view, I might look at this from the perspective of coverage. I need to aim for as much coverage as possible to validate the quality of the product before it can go into Production. Anyone who's ever been involved with testing knows this is a significant task, takes time, costs money and can be a blocker to implementation.
If I look at this from an "Outside In" perspective, I'm likely to consider what's important to my user base. What are the key business processes that the product will be used to support? Where are the high-risk areas, for example those relating to financial data, month end processing etc? What's the impact on the end user if I don't cover an element of the product in my UAT? Asking these questions will allow me to focus the UAT effort and ensure the activity is focused on business value and priority.
A final example – my role at LexisNexis provides me with multiple opportunities to drive and implement change. There is a danger that change becomes overly complex and difficult with poor adoption if we focus too much on technical, process or tooling detail that doesn't add value. By taking an “Outside In” approach, I can focus on solutions to the problems we are trying to overcome and the impact of implementing positive, value add, pragmatic change to my colleagues and the wider business.
To summarise, applying an “Outside In” approach allows us to focus on what is important to our customer and helps us to apply commercial perspective to our function.