The whole "Project" to "Product" concept is well understood in the tech industry and has been incredibly helpful in shaping mindsets in shifting away from thinking of software as a defined project with milestones and an end date to something that needs to be nurtured and cared for as it evolves. Software, particularly cloud software, is very much an organic living and growing entity that needs to be understood and managed as such. It is not built and then put into "maintenance" mode.

Moving from a "Project" to a "Product" mindset is a big undertaking. But what about the organizations that want to get into modern bespoke applications but still have a "shrinkwrap" mindset? That is, software is bought, installed on a computer and done (the world of Microsoft Office in a traditional IT sense...)! The gap created is an even larger hurdle to overcome in modernizing an internal organization's technology.

This post is going to try and explore some lessons learned (or still being worked out) on our experience working with an incredible organization that was essentially "shrinkwrap" based when we first met and has gradually been moving towards a product / offering mentality.

What is an Offering?

A product offering represents the entirety of the capability that provides some value to the stakeholders. That involves everything needed to invent, build and run the offering from cradle to grave. This is unlike the shrinkwrap mindset that sees software as something bought (likely on a CD!) that is fixed in how it behaves and the interfaces it offers. An offering can be built around COTS, something that might be typical with business intelligence, customer relationship management or enterprise resource planning solutions, but now more than ever they are being stood up inside organizations around bespoke cloud applications.

The scope of difference can be likened to buying a hamburger vs owning and operating a McDonalds. The scope difference really is that big. Yes, you can buy a hamburger, but once you get it you don't have any of the equipment or toppings needed to customize it to your liking. However, moving up to an entire store is a big step that requires a whole other level of finance, marketing, operations, staffing and capital investment.

Who's Responsible for What?

The first step in helping to shape the mindset of a shrinkwrap organization is to uncover the scope and diversity of roles needed to support an offering. These roles and associated skill levels are wildly different from traditional "IT" departments.

We like to capture the roles and responsibilities in a RACI model. Here you can see a template that we use to help identify key roles for an internal SaaS offering:

There are many ways to divvy up the roles, however, the important part is to ensure that they are explicit and documented so that expectations can be set and gaps can be effectively identified.

A Lot More than Just Development

Something that should be instantly apparent from the above RACI; there are a lot of roles, outside of development, needed to run a successful offering. From the product side of things, to client success, operations and security. Each of these teams provide distinct areas of deep expertise that, once a certain scale is reached, is dangerous to compress into a few individuals. There are few individuals who can be an A+ developer, tester and business owner and client success rep on any given day.

The RACI provided is intended for a medium sized offering, and already the development component of the offering is about 1/10th of the ingredients. From a headcount ratio perspective, this configuration might see 1/4 of the headcount in the development team with the other 3/4 assuming the other roles.

Here is an example team structure that can demonstrate how things can get out of whack. Conway's law applies to more than just the software architecture, we've seen it also applies to an overall offering.

The above example shows an overall offering team of roughly 22 headcount (of which many outside the development team hold multiple roles in the organization). 11 of the headcount reside in the development team, representing 50% of the overall offering. Considering other obligations, it is more like 18 dedicated headcount, which makes development 61% of the team.

The problem? When the majority of the team is concentrated in one area, that team ends up becoming the hammer (and we all know developers like to code!). The issue is that work is constantly pushed to development with the expectation that more code will resolve the issue. In many cases it can, but certainly not in the most efficient ways. Coding around user education or onboarding is a huge increase in time and complexity (think in app wizard vs shared Google Doc).

Essential Roles

In order to deliver on a successful, professional offering there are a minimum set of roles that must be filled. The following sections outline what the roles are and what their focus is in terms of leading and contributing to the success of the offering. You'll note that none of the following roles are developers!

Offering Owner

A development team (typically) doesn't own the overall offering. It isn't impossible, but the ownership typically comes from more of a business capability within the organization. The Offering Owner is the bridge between the strategic needs of the organization with the general management understanding to ensure the delivery team has the right funding / staffing / prioritization to be successful with the delivery of the project. The highest level KPIs should be coming from the offering owner and guide all activity from the Product Owner down to the Development and Client Success teams.

At the end of the day the Offering Owner is what makes the lines of code count. They ensure the right lines of code are being written, legacy lines of code are being removed and that the value the lines of code create are being realized by the broader organization.

The buck stops here.

Product Owner

The Product Owner is responsible for managing the various stakeholders to build a refined backlog that reinforces the strategic goals of the offering and are well understood by the various execution teams (client success, development, operations, quality, security).

The Product Owner (along with the Offering Owner) are responsible to drive a linkage between the work the team is delivering on and the value it is bringing. This linkage is a huge differentiator in terms of motivating the team and empowering all members to make decisions with the organization's strategic priorities in mind.

Client Success

I could write a whole other blog post on moving from "Customer Support" to "Client Success". Typically a shrinkwrap organization will think in terms of customer support. Their job is to solve your problem, vs empower you to solve your own problems (or better yet, provide feedback to product to eliminate the entire scenario). How do these look different?

Let's consider a common scenario. A user accesses an offering, finds they are not a member of a required group and sends an email to support for help.

The traditional support approach, would treat each request individually, reply to the user to inquire what group they should be a member of and then use their elevated privileges to add the user to the group. Support would send an email once complete and the user would be happy. Sounds good?

The problem with this approach is there are an infinite number of times this will happen, and completing one ticket never addresses the root cause. A client success mindset would allow this to happen a couple of times, then say enough is enough (our clients aren't being successful!). They would then lead a two pronged approach. First, create onboarding material to inform group owners the steps they must take to add a new member to their group and that it must be done proactively before the offering can be leveraged. Second, engage product to develop a way for individuals to find who their focal point should be within the offering. This approach would eliminate a large percentage of future requests and give client success more bandwidth to devote to higher value activities.

Security

Security is not last in the list. Security is actually pervasive across all aspects of the offering. From strategy, to design, development, operations and client success. Each of these aspects can result in significant security incidents if not properly managed.

It should be noted that having an individual on the team with the word "Security" in their title does not change the posture of an offering in real life. It might check a box, but it does not prevent attackers (or mistakes) on a daily basis.

The role of security is to have an understanding of the current posture from an architectural perspective as well as to ensure the right tactical systems and processes are in place to de-risk the offering. This big picture and detailed thinking is a tough role to fill. For any of the insights to be effective the security capability must effectively interface with the Product Owner and Business Owner to ensure the risks of the current offering are understood and that actions are being taken to close gaps where unacceptable risks are identified.

Closing the Gap

If you are currently leading an organization that is looking to move from shrinkwrap to robust offerings, I hope you have taken away that it is an enormous (but possible!) delta. If you are currently working with an organization that comes from a shrinkwrap mindset, prepare yourself for a lot of repetition and reiterating that they are very different capabilities with very different risks and benefits.

Starting a reading club with Project to Product is a great starting point, and depending on your industry or government organization, there is probably (hopefully!) at least one other source of inspiration that could be leveraged. Despite having over two decades of technology experience, I personally still get looks of disbelief and "that's nice" when explaining to clients the large difference in installing Word, or using a shared Windows drive compared to operating a robust offering worthy of their users.

Do you have any interest in helping take important organizations through the journey of shrinkwrap to offering? If so, we'd love your help! Have a look at our open positions!