Great products are born out of grand visions that require thinking outside the box. This post illuminates the importance of end-to-end thinking and design to create true business value.
In my previous post, I outlined 5 key principles for digital transformation in public safety and emergency medical services. Designing systems end-to-end was one of those principles and, frankly, I consider this to be the most important of all.
Designing truly great products (I am using this term deliberately, as "system" appears to be more technology-centred) requires you to think about the bigger picture first. Only then, you can start working on all of those details that make up a great product. In both steps, an interdisciplinary setup, in which all impacted stakeholders are involved and can strike compromises, is key to success.
Humble Beginnings?
At the beginning of any endeavour stands a vision. This vision could directly result from the company's vision or mission statement, but could also have been formulated on a departmental level or even from the perspective of a project team.
In any case, you need to make sure that your endeavour's vision realises the strategic vision of your company and/or department. If not, then your vision would not be aligned with what the rest of the company is (to be fair: presumably) doing. In consequence, you would not generate as much business value as you could. You should look at it like this: even the smallest vision that you help become reality should be part of something bigger - a grand, strategically important goal. Sounds pretty good, doesn't it?
There are, naturally, many approaches on how to achieve this strategic alignment. Let me outline one exemplary, very simple approach:
Take a piece of paper on which you write the following from top to bottom: your company's vision or mission statement, your department's yearly goals and your currently ongoing endeavours with their underlying visions. If you can not, starting from an endeavour, draw a line to one of your department's goals and, continuing from this goal, one to an element of the vision or mission statement, you have a strategic misalignment.
Some of you might be screaming "SAFe!" here, but in the above case, the main focus lies on transparency, not steering. The observations that you can make by such a quick analysis are often very interesting - please comment below in case you want to know more.
Interdisciplinary Teams
One thing should become clear: whatever your department's goals or endeavours' visions are, they are still just one piece of the puzzle. Figuratively speaking, it is even quite likely that your piece does not fit to the other pieces, e.g. from different departments, that are supposed to make up the whole puzzle.
Let me give you an example: most emergency medical services share the vision of bringing fast, effective medical care to the patient. There is, however, a trade-off between fast dispatch (the dispatch department's vision) and collecting the required amount of information for paramedics or emergency physicians to deliver targeted medical care. Now imagine that you need to implement a new alarm system that lets dispatchers select and alert ambulances. Very quickly, you may find yourself to be caught between two stools.
How can you avoid that? You need to set up interdisciplinary teams that help designing and operating your product. In the above example, this would mean that the business representatives in your project team should at least comprise dispatchers, paramedics and emergency physicians. When jointly refining the product backlog for your alarm system, potential trade-offs would soon become apparent and it would be the product owner's task, who is ideally in a neutral position, to resolve them.
Once again in a nutshell: use interdisciplinary teams for designing your product, as only in this manner, conflicts of interest will become apparent. As usual, agile methodologies can only make such conflicts of goals become visible - but not solve them :).
End-to-End Implementation
By starting with an alignment of your endeavour's vision to the bigger picture, we have arrived at an interdisciplinary approach that helps your product to deliver value to all of its users and affected stakeholders. Now, the "only" thing that is left, is to make sure that this value actually gets delivered - by implementing your product.
Again, trying to understand the bigger picture as early as possible pays off. I like to differentiate between the following aspects of an IT product:
Software aspect: relates to the stability, performance and usability of your software. As with regard to the latter, your software product's users have different backgrounds and needs. You can, for instance, capture them in personas and then validate your software's usability in scenarios that should be as close to reality as possible.
Interface aspect: almost always, your product has interfaces to other products, be it "machine-to-machine or with some humans inbetween". Make sure that, as early as possible during the implementation, you implement or, at least, emulate those interfaces in order to spot obstacles or inefficiencies in end-to-end processes.
Hardware aspect: even a great piece of software can lead to bad user experience when it is used on the wrong hardware. Wrong does not necessarily mean that the hardware is bad; it could simply be ill-suited to the way in which it is used or not fitting to the operating environment. In my experience, the best approach to determine the right choice of hardware is by conducting experiments in the field; you will find more on that topic in a later post.
Environmental aspect: last but not least, your product is used in a real-world environment in order to generate business value. This value can only be delivered under certain boundary conditions (i.e. in specific environments) and under the assumption of "proper" execution of business processes. This implies that you are responsible for ensuring that your product is operated in the right environment and in the right manner. Oftentimes, this is far from easy.
All of the above aspects should be considered during the implementation of a product, thereby extending the concept of end-to-end beyond the typical process-centric interpretation. Experimental, iterative approaches are, in my experience, well-suited to deal with the complexity of optimising a product across the various aspects.
Wrap-up
The bigger picture, that we all so frequently talk about, has many facets and is, often, very hard to grasp. When designing products, we should nevertheless strive to understand it as well as possible, so that we can deliver true business value. This is especially important in mission-critical environments, where even small inconsistencies in end-to-end design can lead to potentially catastrophic outcomes.
Are you further interested in the topic? Register for the free first 30-minute webinar of my new "Booster Webinar" series, that is to take place on April 1 - I guarantee that this is no April Fool's Day joke :). But hurry up, participation is limited to 15 attendees. You can register HERE.
תגובות