Product Strategist: Regulatory Match and Regulatory Fit

Out on twitter, productmanagers shared a reference to this article,  "Study Explores Motivation behind Decision Making in New Product Development Teams" in the Carolina Newswire. The article can be found at http://tinyurl.com/c5hzbl.

The article covered research on product teams. They concluded that "'regulatory match’ effects in teams are stronger than the effects from ‘regulatory fit.’ It boils down to a team aligned towards some 'regulatory focus' or source of motivation like a goal will stay on goal, rather than listen to management when management is directing them towards another goal. Management has more success directing teams that are less focused on a goal, or who individually focus on the goals of their functional and business units, rather than team goals.

After all these years of "team" religion, surprise, management doesn't like those cross-functional teams that somehow become focused on the teams goal, because they won't focus on management's brand new, shiny, goal of the week. Oh, well, back to the B-school curriculum drawing board.

As in intra-organizational behavior, this shows up in inter-organizational behavior as well. In marketing, we listen to our customer pool, and we deliver on the customer's collective 'regulatory match.' When we try to lead that customer pool, we are trying to change their 'regulatory fit." We hardly ever succeed at that latter. We establish regulatory focus early in the adoption cycle, or maybe an earlier vendor did that for us, and we can't escape it. We are stuck with the definition of the category even as we differentiate our products and ultimately blur that definition.

Our product becomes our 'regulatory match,' and we reject any 'regulatory fit." Many agile practitioners see themselves as the determiners of 'regulatory match,' and see product management as 'regulatory fit.' Ouch! Frankly, I see my need to generate cash flow, and obtain budget allocations as my 'regulatory match.' I'd really love it if the organization-spanning 'regulatory fit' would protect me from the executive head snap, but, I'm not a team. I'm one manager that looks like a team. And, like strategy thickness, or working several strategies simultaneously reducing the threat from bad strategic and tactical assumptions, populations or teams have a effects similar to that thickness. Force dissipates among the many.

Taking this back out of house, back to the inter-organizational of the customer base, marketing to a prospect base filters it and results in a smaller customer base. Selling makes that customer base even smaller and at the same time more focused. Marketing and selling increases 'regulatory match.' Listening to the customer in developing upgrades, and customer attrition further increases 'regulatory match.' The arrival post-tornado of the herd of fast followers expands the offers the customer base is exposed to, so many move on, leaving us an even more highly tuned, and highly focused "team" of customers with a vast 'regulatory match.'

So is it any wonder that trying to push another discontinuous innovation at that customer base long after product introduction fails? Your own mangers can't do it, so why should you?

The notion of 'regulatory fitness' does come to the rescue here. Diverse goals provide management with the ability to tune 'regulatory fitness,' so a new 'regulatory match' is formed. Taking that discontinuous or radical innovation to a completely new market provides you with two distinct and diverse customer bases. They will remain separate for some time to come. Eventually, you can cross sell them and move them together into a single market. You might need a new product to solidify their emerging 'regulatory match.'

It is this kind of stuff, the tempo issues around continuous and discontinuous technologies that drive product roadmaps--global stuff. There is plenty of latitude in the local stuff, the order of development of the portfolio of minimal marketable functionalities. Both locally and globally, however, there is always cash flow and budget. If you've ever been in a bootstrapping startup, you already know what agile product management is about. "Hey, do you have twenty, so I can get this critical API?" "Hit me on payday. That's next week. I need to get this done. Go ask the founder." Do you want to code or deal with the cash flow and budget? If, as a developer, you’ve never had to ask for money, ask yourself why. If the VP of dev is paying you with a personal check, don’t ask why. It’ll be ok. Code on. There never was a waterfall until the organization was profitable.

If the sales rep really wants X by next Tuesday, I'll have him take you to lunch, and bring you meals on the weekend. Don't make it too easy on him. Cash will flow!

Other researchers, reported in 2004, looked into customer homogeneity ('regulatory match') and customer heterogeneity ('regulatory fit'). It boiled down to homogeneity for continuous or sustaining innovations, i.e. releases 1.1 and beyond, and heterogeneity for discontinuous or radical innovation, i.e. releases 0.1 to 1.0.

Product managers don't get hired until after release 1.0, so we live in the heterogeneity space, and we live with various 'regulatory matches' across the organization and market. Don't change the world. They did that before you showed up.

Let me know if you chuckled. Leave a comment. Thanks.