Dear all,
as you may have noticed, there was no Weekend Reading for the past two weeks. Inspired by some recent workshop discussions, I intended to write a quick post on product-based IT. However, as the subject is complex, I ended up with a rather long treatise. Even after some serious shortening, it’s still a longer read this time (as usual, I have also added some links below that provide additional views and insights on the topic):
Product-based IT in our view starts from the concept of a „product“: Products are a combination of goods and/or services that are purposefully created to fulfill understood stakeholder needs with the intention to derive benefits and/or profits from them.
This definition implies three key components: Stakeholders, Needs, and Business Value. Any product’s purpose or product vision is demarcated by them.
Typical consumer products start from a human need. Technology is applied to cater to that need in the best possible way. After finding problem-solution fit, a business model is developed to create the value that makes the resulting product a viable business.
IT products start from a desired business outcome that – if fulfilled – translates into measurable business value (think profit, customer satisfaction, …).
The desired outcome is usually identified by a management stakeholder – often in a quest for some strategic goal. Technology is then applied in pursuit of the outcome with the intention to create the largest possible value for the business. Typically this involves creating benefits for other stakeholders – internal users – in the process as well.
Many IT projects start out this way, but over time they become „demand-driven“. As IT is understood to be a „service provider“, any remotely impacted stakeholder feels empowered to demand changes to locally optimise the part he feels responsible for. The original intention – to drive value by striving for a particular outcome for the business overall – slowly vanishes.
For that reason, many IT products end up looking like Mod Scooters (as in the GIF above) with lots of „stuff“ that – at best – adds value under very specific circumstances. Some of my colleagues go as far as calling them „Frankenstein applications“.
Moving to product-based IT, therefore, requires three fundamental changes:
- understanding IT as actively managing digital tools in pursuit of business outcomes
- moving from delivering any stakeholders‘ demands without qualifying intended business benefit to deliver only the ones that entail significant value for the business overall
- actively applying Pareto- (aka 80/20) and YAGNI- (“you ain’t gonna need it”) rules to keep the resulting product-focused in order to avoid maintenance- and other follow-on cost
(A fourth aspect to be considered may be the user experience for „internal users“ that has profound productivity implications and deserves a separate post.)
Business value in our view is defined by four key parameters:
- number of people impacted by the requirement – stakeholders, users, …
- the magnitude of the impact – time, $$, …, gained or saved by implementing and operating the solution
- strategic value – how much the requirement is aligned with desired strategic outcomes
- delivery effort – the effort or man days required to deliver the requirement
Despite the parameters, the business value of a demand is often not immediately comparable and still requires judgement. (Shortening this post, I have moved an example to the bottom). In addition, strategies (Business as well as IT) are often not clearly spelled out, so assigning strategic value may turn out to be difficult. The principles do apply, nevertheless.
To make the concept work, Product Managers and Product Owners need to regularly have informed discussions with all relevant stakeholders in order to agree business goals and jointly assign value to requests applying the principles above. This can for example be achieved in the context of a quarterly IT business planning session or similar (e.g. SAFe Portfolio or PI planning sessions).
The key mindset switch required, is to move from delivery of demands to actively and intentfully managing for maximum value in pursuit of strategically mandated business outcomes.
“Product management is about insights and judgment, both of which require a sharp mind. Hard work is also necessary, but for this job, it is not sufficient.”
― Marty Cagan, Silicon Valley Product Management Legend
There are a host of other factors to be considered. UX for internal users being one, see above. The following posts cover some of these additional aspects:
How to Build Better Internal Tools –
by Richard Holmes. A series of practical hints for creating better internal applications.
Internal Product Management: the Good, the Bad and the Ugly –
by Black Swan Farming. Should product management principles be applied internally?
Tldr, my apologies. If you have made it here and are still wondering what the Mod Scooter is all about, send me an invite and I will gladly take 45 minutes to walk you through the intro presentation of our product-based IT workshops.
Have a great weekend,
Godehard
As for the promised example…
Let’s consider the following – entirely fictional – examples:
A company is moving offices. Unfortunate in times of pandemic, the new building was designed as open-plan office with on-demand desk assignment. Contributing to the challenge, the surrounding metropolitan area suffers from traffic congestion. Employees will easily average 45 minutes for their commute – one way.
With current safety rules in place, 1000 employees less than originally planned can be accommodated in the new building.
If desks were assigned on a first-come-first-served basis, up to 1000 employees would find the office already out of capacity upon arrival and needed to return to their home offices.
Top management is obviously concerned! The IT department asked to find a solution has the strategic remit to „Boost focus on the core business by improving every employees‘ office life.“
Calculating business the value of solving the above problem: The first two factors – nº of people impacted and magnitude of impact – are easily computed (assuming a monthly base):
(1000 people x 20 days) x 90 mins wasted (you could multiply that with the average hourly wage if you wanted a $$ figure)
Obviously, employee health falls squarely into the department’s mission, so let’s assign it a 10 (stipulating a 1 to 10 scale) for strategic value.
The result: 20.000 x 90 x 10
The IT manager in charge explained that an „office desk pre-booking app“ can relatively easily be created, building from a facility management system already in place.
For that reason – using the Fibonacci scale commonly applied in Agile effort estimation – we could assume the relative effort to be 3 (one could alternatively use person-days estimates).
As a result the equation would now read:
Business value: 20.000 x 90 x 10 / 3 = 6.000.000
Let’s compare this to a request to facilitate an employee’s office move, assuming it impacts approx. 5000 people across the company per month, and saves around 3 hours of effort per move. It fits into the department’s overall remit, but there is no management sponsor pushing it. For that reason we assign it a „5“ for strategic importance. Implementing the „moving assistant“, however, is more complex than the „desk pre-booking“ app, so consequently, it’s estimated an „8“ on our relative effort scale.
The resulting Business value: 5000 x 180 x 5 / 8 = 562.500
For good measure we compare this to a third demand, asking to rationalise and speed-up the internal delivery of office supplies. Initial analysis shows that on average the every employees orders some office supplies every six months. With 250.000 employees, the order size averaging 33 Euros, and procurement forecasting 10% cost improvement, we have some basic information to start calculating. On top logistics promises 24 hours faster delivery – if certain machine learning tools could be applied – which would however increase comparable implementation effort to a „21“.
Business value: (33/6)*0.1*250000 / 21 = 6548
As a result we end with a business value in – sort of – Euros without really considering the benefit of 24h faster office delivery (does it matter at all under normal circumstances?).
A seasoned Product Manager would undoubtedly thoroughly question – if not expediently reject – the last of the three demands. Even without considering average salary per minute in the above examples, or the „value“ of faster supplies delivery to make the calculations more comparable, it seems obvious that there is little to be gained from the last demand.
Especially when considering the IT department’s strategic direction of „…improving every employees‘ office life.“