Why Spock should have been a Product Manager

I am definitely more of a Star Wars than Star Trek kind of guy, but over the Christmas period I found myself watching an old episode of Star Trek, The Wrath of Kahn (1982). It was during the final scenes of the movie that I realised Spock had missed his calling by not following a career in product management.

When faced with a choice of two impossibly difficult situations - his spacecraft being destroyed with the whole crew onboard or sacrificing himself to save the crew, Spock uttered some immortal words to Captain Kirk

“The needs of the many outweigh the needs of the few”.

Some pretty prophetic words from Spock and a statement I am sure anyone who has ever been involved in any type or level of product development, engineering or design would be quietly nodding their head in appreciation at; or shaking their head with a subtle roll of the eyes. A lot of us have had numerous situations where we felt the same way Spock did (well hopefully not to the same level of decision that Spock had to make!) but a similar conundrum. 

I know I have.

‘This really big / important / high-value client needs this unique / bespoke / customised work done for their program. It is really important we get it done for them’.

I am certain anyone who has been involved in any part of software development will have heard this statement many times during their careers. Being able to customise software to meet client demands and requests definitely helps win new deals and retain clients so is it is very easy to attach an objective measurement (usually monetary) to why doing this type of work is important (or conversely attach a monetary amount to the lost deals or clients that can be attributed to not doing this type work). This is what makes this question particularly difficult to refuse. It is easy to attach an ‘actual' monetary value to doing or not doing customised or bespoke development work. If we do that work, we will win a $500k deal or retain a $500k client. If we don’t, well…we lose that money.

But it is my view that this is a far too simplistic way to view this and not a true valuation of what doing this type of work could and does really cost a business. Doing any unique or customised development work (which I would define as any development work that does not impact more than 95% of your existing client base) can create a very real potential of losing a lot more revenue (and therefore profit) than it actually creates. It is just a lot harder to objectively account for this revenue and it does not exist - yet. There are obviously the direct costs of any development work primarily in the form of the hours required from the various teams doing the work, but the real cost of this type of work is the ‘opportunity cost’. By focussing your resources and time on doing more unique, customised work, you are directly slowing down development on your core product provision. Your core product is the backbone of your business. It is what you should be relentlessly focussing on developing and improving. It is where you should be differentiating from competitors. If you are losing sleep over anything around your product, you should be losing it because of the excitement you have over the work your are doing on your core product, not the work you wish you were doing.

This is where I think Spock got it right. He realised any decision that prioritised the needs of the many over the needs of the few, was the right decision to make. And I think as product leaders, we have to follow the same mantra. By doing this work, does it impact the many or the few? If it is a decision that impacts the many, in almost every single situation, it is the right decision to make. 

Similar to my last post, I could be seen as oozing hypocrisy for writing this. There have been in many situations where I have prioritised more bespoke work over core product development in the last twelve months. I might have made some different decisions in hindsight but I do not think it is quite as simple as ‘yes’ or ‘no’ to customised development requests. There are going to definitely be times where the right answer is taking some time (and resource) to focus on some work that impacts very few, if any, other clients. This cannot be avoided and it would be foolish to simply turn down every bespoke development request. Listening carefully and discussing every request is critical (and I find in a lot of these situations, your product might already do what is being requested, but just slightly differently). It is when bespoke or customised work begins to directly impact core product development that the lost opportunity cost becomes something very real and potentially very painful. Focussing a small proportion of of your development time and resource to more unique requests should not directly impact core product development. By small proportion, I would say no more than 10% of product and engineering resource per quarter, which should still give sufficient resource to build a few smaller, unique features for individual clients, while still maintaining full momentum against the core product development roadmap.