4 Aspects To Consider In Your Product Configurability Process

SaaS Product Managers can learn a few things from Subway when it comes to "product configurability".

As we all know, every Subway customer is able to customize the kind of sub they want: from selecting the bread, to choosing the protein to electing vegetables & sauces.

‍

Here are some aspects to consider when developing your configurability story:

1/ Not everyone has the time to configure

If I'm on the move and need a quick bite, I don't want to go through the "subway building" process. I'd like to just point at a menu item & have the server snap up a bag for me without the whole questionnaire.

Similarly, if your product offers say, an email or workflow builder, every user may not have the time, energy & skill to build something from scratch.

Recommendation: Always think of a templating layer to bootstrap the process. For example, Drift offers a number of playbooks to help users get a head start on setting up their live chat bot.

2/ Over-Granularizing Configurability can lower productivity

Imagine if the Subway server was to ask you exactly how many pickles & cucumbers you wanted on your sandwich & the exact quantity of "Thousand Islands" sauce you needed on there. That level of configurability would be annoying & pointless.

Thus, it's essential to identify thoughtful configurations. If you overdo it, it might get in the way of finding quick time-to-value.

For example, a document author on DocuSign can setup signature fields. Forcing the author to further choose a different set of allowable signature styles (draw, upload, type) per device type (mobile, tablet etc.) seems like an overkill.

3/ Choosing between local/global configurability levels

If a group of friends order their regular subway salad every time they visit, then asking each one of them to go through the "editing" process can be counter-productive.

For example, Gong can tag sales conversations where any mention of a competitor was observed. The list of competitors should ideally be set at a global account level & not at a (local) sales rep account level as the competitor list would unlikely vary across reps.

4/ Configurability always comes with a cost

Tradeoffs need to be made. More configurable solutions require longer release cycles.

Example: When we built an employee onboarding solution (AfterHire), we noticed that every org had their own process. Thus, we invested more lead time on building a workflow editor for maximum configurability because we knew that we'd drown our product in change requests later on if we didn't.

However, some configurations (like customized system emails) didn't make the MVP cut as that would have delayed releases without much added value.

A middle ground I often see is that a configuration is made available but it's just not surfaced to the end user in terms of an interface, rather kept at the backend using config files or database flags.