When it comes to designing, building and configuring OSS, there is a tendency to have a functionality delivery mindset. That is, if we can get our OSS to meet each functional requirement then we tick the box and move on to the next. There is usually a long list of requirements that need to be ticked off, so we don’t have time to go through the refinement cycle.
This poses a dilemma because simplification is so important, not just for our OSS, but for the customers we’re delivering for. The triple constraint principle shows some of the reasons behind this concept.
The simplification mantra (which could be translated into requirements for you tick off) consists of:
- Simplify how we design and build our products
- Simplify the products we sell (and bill)
- Simplify how customers use our products
- Consider each of the three statements above from a triple perspective:
- From our own viewpoint
- From our customers’ viewpoint (eg service providers)
- For their customers’ viewpoint (eg the customers of the service providers)
For example, from perspective B – how can CSPs simplify the design and build of products; simplify how they sell and bill them; and simplify the user experience for their customers.
If you’re tackling simplification from only perspective A (and maybe B), then you’re not considering simplification across the whole life-cycle.
C will buy from B if B’s services make C’s life easier.
B will buy from us if our products / services make their life easier. Frankly, they don’t really care about perspective A, but that’s usually what we’re thinking about right?
To be equally frank, most OSS already have millions of features, so delivering new functionality is probably less important than streamlining the use of existing functionality in most cases.