If you’re a business analyst or product owner working in IT, do you see yourself working on a product? Maybe you should. Here are some ways to define it.
Hey Kent. Found you via your comment on John's latest TBM 382 about 'product when you don't sell a digital product'.
You are talking about internal products here, but have you experienced any organisation operating product teams who aren't actually building software products, but are instead responsible for package / commodity software?
For example, in the retail industry we operate large warehouses. These use software to operate the warehouse efficiently - to track goods coming in, ensure they are stored in the right place, retrieved and sent to stores and customers appropriately, and so on.
As you'd imagine, there is a lot of customer demand for this software (given the large number of warehouses in the world), and there is also a large number of vendors who offer the software. This has led to good package software being available for a reasonable price. So, most retailers procure 'warehouse management systems' (WMS) from software vendors (back in the olden days we'd call it COTS - commercial off the shelf software). Very few retailers have chosen to develop their own WMS, because there is no benefit in doing this. In the same way that very few companies choose to develop their own spreadsheet solution - they just use Excel.
My question is, have you experienced teams trying to operate as product teams, whilst being responsible for software such as the above?
I'm experiencing it right now. One team I work with uses HubSpot as a key part of the overall "product" we use to enable online sales.
I think I've referred to internal products as software that organizations build *or configure* for use inside their organization. Use of COTS or SaaS products is an aspect that differentiates internal products from products that organizations sell.
And from the perspective of applying product practices using COTS or SaaS fit just fine - after all product *should* be about is a problem worth solving and what's a good solution to solve it. If a COTS or SaaS product is a good solution, great!
Hey Kent. Found you via your comment on John's latest TBM 382 about 'product when you don't sell a digital product'.
You are talking about internal products here, but have you experienced any organisation operating product teams who aren't actually building software products, but are instead responsible for package / commodity software?
Take care,
Dave
Hi David,
Thanks for reaching out!
I may have experienced that, but to make sure, can you give me an example of what you mean by package/commodity software?
- Kent
Hi Kent, what a speedy reply! :)
For example, in the retail industry we operate large warehouses. These use software to operate the warehouse efficiently - to track goods coming in, ensure they are stored in the right place, retrieved and sent to stores and customers appropriately, and so on.
As you'd imagine, there is a lot of customer demand for this software (given the large number of warehouses in the world), and there is also a large number of vendors who offer the software. This has led to good package software being available for a reasonable price. So, most retailers procure 'warehouse management systems' (WMS) from software vendors (back in the olden days we'd call it COTS - commercial off the shelf software). Very few retailers have chosen to develop their own WMS, because there is no benefit in doing this. In the same way that very few companies choose to develop their own spreadsheet solution - they just use Excel.
My question is, have you experienced teams trying to operate as product teams, whilst being responsible for software such as the above?
Speak soon,
Dave
Great question and a great topic for an upcoming issue of InsideProduct!
Thanks for clarifying.
I'm experiencing it right now. One team I work with uses HubSpot as a key part of the overall "product" we use to enable online sales.
I think I've referred to internal products as software that organizations build *or configure* for use inside their organization. Use of COTS or SaaS products is an aspect that differentiates internal products from products that organizations sell.
And from the perspective of applying product practices using COTS or SaaS fit just fine - after all product *should* be about is a problem worth solving and what's a good solution to solve it. If a COTS or SaaS product is a good solution, great!