Productizing your Deployment – Part 1


What the heck is “Productization”?  Is that even a word?  Not according to Merriam-Webster, but it’s a word that you will want to introduce to your vocabulary!

We all absolutely love implementing Salesforce – the thrill of setting up a new org (aahh that new org smell!), getting business requirements, and building out exactly what the business needs.  Who doesn’t love doing this part – I know I sure do!

So what happens after “launch”?  Many companies continue at the same velocity as they had during the build phase – which may keep noisy users at bay, but how often do we think about those non-noisy users?  How often do we think about “implementation fatigue”?  What about other areas of the business that want to onboard?

Often, we end up thinking of such things months or years down the road when data starts becoming shoddy, management stops managing from the tool, or you find the users have created a thousand Excel sheets with PivotTables to actually output useful reports because their data source keeps changing.


So what is “Productization”?  Productization is the process of taking your platform and taking it from the adhoc building phase to a more of a traditional enterprise platform “tool” that is predictable, stable, and trusted.  Picking the phrase apart – you are essentially making a “closed” product that your users just pick up and use, similar to how they would use Excel, Word, etc.

One thing that many people confuse with a “Productized” solution is one that is static, closed, or non-responsive to changing business needs – absolutely not the case!  This is where you start really exploring and implementing those fancy themes that consultants throw around such as governance/change management, formalized ideation, or formal on-boarding processes.  You want to create a PRODUCT.

This blog post is the first in a series that will discuss the overall themes and approaches of a “Productization” roadmap.  Today we’ll be talking about user expectations/management, speed/velocity of change, and involving your users in the ideation process.

calm1Let your users breathe!

The double-edged sword that is is that it’s incredibly configurable…by anyone in the organization.  This ability is second-to-none when we’re building and honing in the platform, but all of that effort is leading you to your “release version [x]”.

One of the greatest hurdles to any implementation is adoption; many adoption approaches can be utilized such as “creating [x] records per week”, “managing from the tool”, or “compensation driven from the tool”, but for those doing day-to-day work in the system stability can mean just as much or more than anything else.

Think about it – would you look forward to using a tool at work that you never trust is going to be the same tomorrow?  How much effort would you put in to learning how things work or much less how to make them more efficient if tomorrow everything could change?  Having a tool that is predictable fosters an environment where users trust the system and invest more time/energy to using it.

Slow your roll….

This also introduces an almost backward concept – slowing down the speed at which your business customizes  Out of the gate, you are making objects, fields, rules, and writing code to beat the band.  Once you get to “release version 1”, you need to switch your thinking away from “YES!  THERE!  HOW’S THAT??!” to “Yes, let me understand exactly what you’re trying to do, and how it can benefit or detriment the entire organization”.  (ok, that’s a pretty major generalization, but roll with me here…)

To associate a silly visual – “the cockroaches scatter when you turn on the lights”.  The same visual can be applied to users and change – if you change your system haphazardly, your users will scatter!

No, I did not just compare users with cockroaches.  🙂

Ideation Collection and Execution

Very few things have the impact on the overall success of your solution more than a fully engaged user base.  Providing your user base with a forum where they can bring new ideas to light, have prioritization input on the implementation of said ideas (with the assistance of a steering committee), and can bring fixes/improvements back to their peers is both empowering and invaluable.

Next up…

Once you throttle back the engines and make the current users and management stable and happy – then let’s start talking onboarding units and users, but next time!

One thought on “Productizing your Deployment – Part 1

  1. Pingback: Stabilization through Productization | Demand Chain Systems

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s