Outsourcing tasks to your OSS

The jobs-to-be-done point of view causes you to crawl into the skin of your customer and go with her as she goes about her day, always asking the question as she does something: why did she do it that way?
Clayton M. Christensen

Alex Fuller at SupplyChainCowboy.com suggests, “By focusing on the job the customer needs to accomplish, instead of the product you’re trying to sell, you can begin adding value that goes beyond the item in the box. This is explained by Clayton Christensen’s idea that the reason we buy things is because we’re trying to accomplish a job. By focusing on the jobs customers are outsourcing to our products, we can better help them accomplish that job.”

Do you understand your customers/stakeholders well enough to know what they’re really trying to accomplish? Do they even know what they’re trying to accomplish?? What tasks are they outsourcing to our OSS products (whether they realise it or not)?

As I often mention here on PAOSS, the project team and the operations team invariably have very different mindsets, as does the product team. A project team will invariably jump from project to project and have little time to sit alongside the operations team to watch they way they actually use the solutions that have been implemented.

A vendor’s product team must spend time with their operational customers every year (every month / week??). That’s a given, although developers can tend to remain in their ivory towers. For the same reason, the vendor’s implementation team should spend time with operational customers every year too and not just during the handover period, but months after the project has bedded in.

Interestingly, until getting into the process of writing this article, I’d never quite made on important connection. I’d always thought that because the vendor’s implementation team works hand-in-glove with customers on a daily basis, they would know the customer’s needs intimately. To some extent yes, but implementation teams jump from start-up phase to start-up phase and rarely go back to learn from the customer’s experience during the BAU (Business as Usual) phase. The BAU phase is when the customer is in the ongoing process improvement cycle, ironing out any inefficiences that arose during the start-up phase.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.