CIS Security Best Practices Cooperative Product Development

By Adam Montville, Chief Product Architect, CIS

The past few years have been an interesting ride within Security Best Practices, the CIS group responsible for the CIS Controls™, CIS Benchmarks™, and their derivatives. We have grown – substantially. We are, by many measures, successful and fairly well respected. With this growth have come opportunities, and often these opportunities are wrapped in shiny, hard-to-resist packaging. Several years ago, we were a development and support team of perhaps seven people all in (a very small team to affect such amazing outcomes!). Since then, we’ve grown to a division of more than 30 people within CIS. And, we were all chasing those shiny objects.

An Agile Approach

In the spirit of the now-underway World Cup, with all the growth we were realizing, we had a truckload of balls dumped on to the pitch, and for a while, we tried to put each of them to the back of the net – at the same time! So, we adopted scrum and started sprinting, but we were still doing waterfall development, and we certainly weren’t narrowing the number of balls we needed to follow.

To help corral our work and bring some order to chaos at the product delivery level, we looked toward the foundations of agile development, which, while rooted in software development, apply equally well to content development (i.e., CIS Benchmarks and CIS Controls). In those 12 agile principles we found, through fits and starts, some comfort – a sense of acceptance that things will change and with the right information we can make the best choice at the time we need to make that choice. In short, we started down the path of developing our products agilely instead of simply doing agile.

Product Management and Cross-Functional Teams

After we started developing our products in a more agile manner, we recognized the need for further improvement: We needed to positively manage the chaos above the level of development teams. So, we began designing, in a collaborative manner within Security Best Practices and across CIS supporting functions (i.e., IT, HR, Legal, Business Development, Member Success, Sales), a product development process. This process would be user-/customer-focused. It would be data-driven. And, it would empower autonomous, cross-functional teams accountable for positive outcomes.

For such a product development process to work, we had to take a strong “Product Management” approach. This is not a new idea in the industry – it’s been around for a long time – but it is relatively new to CIS. Still, why reinvent the wheel? As such, there are certain principles of product management to which we should adhere. One such principle is to establish, with a nod to Conway’s Law, our cross-functional, autonomous teams. Such teams have every skill set they need to deliver the best possible product immediately at their disposal, they have product delivery management services available to them, and they have – perhaps most importantly – a quarterback.

The Product Owner’s Role

The quarterback of each cross-functional team is the Product Owner. The Product Owner is accountable for product discovery, describing and communicating the product vision, collaborating with support functions across the company (in the context of their product), and for directing the development team to deliver on that vision. The idea of having our Product Owners in place is to execute the product development process so that we reduce risk. With (according to Strategyzer) roughly seven of every ten product ideas resulting in failure, we’d like to realize those failures very early on.

A lot is expected of a Product Owner – there are many stakeholders to manage and decisions to make, and not all of those decisions will make all the stakeholders happy all the time. We do not expect Product Owners to be superheroes – far from it. Like a quarterback, the Product Owner will likely bear the brunt of dramatic failures, but they will also be recognized when they lead their cross-functional teams to deliver a product our users love.

If we move on from the football analogy to that of an orchestra, then the cross-functional team are the musicians and the Product Owner is the conductor. The orchestra is the working team carrying out the mission, the product owner is showing the way to please the audience of stakeholders. Together, the cross-functional, autonomous product development team plays the music our users love.

Product Owners need to truly understand the value proposition(s) their product delivers – the problems solved, who the target users are, the pains they experience, the things that would act as force-multipliers for them, and how our products increase the gains and reduce the pains to solve those problems. With all of this understanding, the Product Owner definitely needs to communicate externally, including presenting/conversing with users, customers, and partners. The bottom line here is that they need to “get out of the building” and interact with users – we need to establish working relationships with 6-10 users for each of our products.

How You Can Get Involved

If you use CIS resources – whether freely available or members-only – and would like to be more intimately involved in the product development of CIS Controls, CIS Benchmarks, CIS WorkBench, or CIS-CAT, let us know.

Our product development process is, in essence, emerging. We are looking forward to becoming more proactive in our product development while we bring these concepts together with our vision of leading global communities to secure the connected world, and we hope you are able to join us.