Product manager interview: Should a workflow be configurable or opinionated?

Prompt and context

You own an approval workflow in a B2B SaaS product. Sales wants every customer to customize rules, while engineering worries about configuration sprawl, a larger test matrix, and support cost. There are 500 tenants, and 40% of interviewees have asked for different rules, but nobody has shown which differences create a distinct business outcome. Decide whether the product should stay opinionated, open configuration, or a layered approach, and explain the evidence, scope, experience, technical partnership, pilot, and review conditions.

This is a product judgment question for product managers, platform product managers, and technical product managers. The test is not whether “more configuration is more flexible.” It is whether you can translate customer differences into jobs, constraints, and repeatable outcomes, then choose a maintainable product boundary. The 500 tenants, 40% figure, and rule differences are interview assumptions, not market benchmarks.

What the interviewer is testing

First, can you separate a requested solution preference from an outcome? Second, can you identify regulatory, permission, or business constraints that cannot be bypassed? Third, can you treat complexity, learning, support, and testing as product costs? Fourth, can you use layers, defaults, and a pilot to control risk instead of choosing between one rigid flow and unlimited configuration?

Questions to clarify first

• Is the customer changing an outcome, approval order, permission boundary, or surface detail such as labels and notifications?
• Which rules involve compliance, audit, data residency, or permissions that a tenant must not bypass?
• How many independent workflows and roles create the differences, and can they be grouped into reusable patterns?
• Are the users administrators or every business operator, and how much rule language can they learn?
• What happens when a configuration is wrong? Can it be previewed, validated, rolled back, and audited?
• What long-term test, documentation, migration, and support cost can the team fund?
• If the first release stays opinionated, what evidence would justify opening one configuration layer?

30-second answer framework

“I would not open arbitrary rules because 40% of interviews mentioned differences. I would map the differences to outcomes, hard constraints, and repeated patterns, then identify which configuration removes a real blocker. My initial recommendation is layered: keep a predictable default path, expose a small set of validated high-frequency policies, and avoid arbitrary scripts or unbounded nesting. I would pilot this with administrators and measure completion time, errors, support cost, and business outcomes before expanding the surface.”

Step-by-step answer

Start by writing the decision goal. For example: tenants should complete a compliant approval without professional services, while a new user should complete the default path quickly. “Serve more preferences” is a means, not a success metric.

Build a difference map. Translate “we need a different workflow” into triggers, approvers, order, amount thresholds, notifications, audit records, and exceptions. Record the outcome, frequency, failure cost, and whether each difference is a hard constraint. If several customers use different words for the same outcome, unify the concept before adding another switch.

Check hard gates before scoring options:

Then compare an opinionated default, open configuration, and layered configuration. An opinionated flow reduces learning and support cost but can push legitimate differences into manual services. Open configuration covers more cases but expands state space, test combinations, and explanation cost. A layered model productizes frequent, verifiable differences while keeping rare or high-risk needs inside a review or professional-services boundary.

Configuration is not only an implementation question. Set a complexity budget for each layer: configurable objects, composition depth, dependencies, permissions, versions, migrations, previews, validation, and rollback. Prefer declarative, finite, bounded options. Do not expose arbitrary scripts, expressions, or cross-object side effects directly to customers. Every option needs a default, an impact explanation, and an audit record.

Run a small, difficult pilot. Select 6 to 10 tenants with different approval constraints, including the default path, one frequent exception, and one high-risk exception. Compare the opinionated and layered prototypes on time to first completion, configuration errors, approval failures, support hours, rule changes, and the core business outcome. The prompt gives no statistical threshold; define success and stop gates before running the pilot.

Let administrators configure during the pilot, not every operator. Provide simulation, impact previews, version diffs, publish approval, and one-click rollback. Require two-person review for high-risk rules. When an automated rejection is not self-explanatory, show the trigger, the required correction, and the audit trail. Accessibility is also a hard constraint: the configuration UI and resulting workflow must be operable and understandable by people with different needs.

Write adoption and exit criteria into the decision. Expand a layer when it consistently reduces manual work across multiple tenants without material error or support growth. Keep a request in a service boundary or reject it when it serves one customer, creates many exceptions, confuses new users, or makes testing intractable. Regularly remove options that have no use so the configuration surface does not only grow.

The recommendation is layered: keep a strongly opinionated default workflow, expose a small set of frequent, low-risk, explainable policies, and keep high-risk permission and compliance rules in the platform. Validate rare differences through services first. Treat flexibility as an evidence-backed capability rather than a sales promise. Review triggers include configuration adoption, completion, error rate, support hours, rule combinations, migration cost, and renewal impact.

High-quality sample answer

“I would not infer that arbitrary configuration is needed because 40% of interviews mentioned different rules. I would first confirm the outcome and whether the difference is a compliance constraint, role permission, approval order, or a surface preference such as labels and notifications. I would map the interviews to triggers, roles, order, thresholds, audit evidence, and exceptions to find repeatable patterns.

I would check hard gates first: tenants must not bypass permissions, audit evidence must be complete, the default path should let a new tenant finish the core job without learning rule language, and every configuration must be previewable, validated, versioned, reversible, and explainable. Anything that cannot be explained or recovered should not be exposed directly.

My initial recommendation is layered. Keep a strongly opinionated default path and expose a small set of frequent, low-risk, explainable policies such as approver mappings, bounded thresholds, and notification cadence. Keep high-risk permissions and compliance rules fixed in the platform. Do not start with arbitrary scripts, unbounded nesting, or cross-object side effects.

I would pilot with 6 to 10 tenants that have visibly different constraints. I would compare the default and layered prototypes on first completion time, configuration errors, approval failures, support hours, rule changes, and the business outcome. Before the pilot, I would define success and stop gates and provide simulation, impact previews, publish approval, and rollback. Administrators configure; operators see a clear execution result.

If a layer consistently reduces manual work across multiple tenants while errors and support stay within budget, I would expand it. If it serves one customer, causes combinatorial growth, or confuses new users, I would keep it in a service boundary or decline it. I would track adoption, unused options, errors, support hours, rule combinations, and migration cost, then remove options with no value. This answers real differences while protecting a predictable default experience.”

Common mistakes

• Use request percentage as the decision → 40% mentioning a difference does not mean 40% share a valuable outcome → classify outcomes and patterns first.
• Treat every difference as a hard constraint → preferences accumulate into unmaintainable rules → separate compliance, permission, workflow, and surface concerns.
• Treat option count as value → more choices increase learning, testing, support, and explanation cost → set a complexity budget per layer.
• Show only a happy-path demo → errors, rollback, and migration risk remain hidden → pilot with real, difficult tenants.
• Make operators write rules → business users inherit platform design cost → give configuration to administrators with preview and audit.
• Ignore accessibility → the configuration UI or result may block some users → make operability, understandability, and recovery hard gates.
• Only add options → unused choices keep expanding maintenance → use adoption and support cost to trigger removal or consolidation.

Follow-up questions and answers

Follow-up 1: The largest customer says it will not sign without arbitrary scripts. What do you do?

Clarify whether this is a contract gate, an outcome, or a preference. If it is a gate, assess whether the customer value justifies long-term platform cost and have security, legal, and engineering review the boundary. Offer a constrained declarative capability or an isolated services arrangement if appropriate, but do not turn one sales promise into the default contract for every tenant.

Follow-up 2: How do you prove a configuration deserves product investment?

It should solve a similar problem for multiple independent tenants, expose an observable outcome, and remain verifiable, explainable, and reversible in a bounded state space. Compare service cost, task completion, errors, and support changes, and confirm it is not a one-customer temporary process.

Follow-up 3: Errors spike after configuration ships. Do you disable it or fix it?

Triage by risk. For permission, compliance, or irreversible side effects, stop new publication and roll back to the last validated version. For low-risk settings, restrict new creation, keep existing executions if safe, and collect diagnostics. Preserve audit and version evidence before changing behavior.

Follow-up 4: The opinionated default blocks adoption in one market. Do you open it immediately?

Confirm whether the market difference is regulatory or core workflow behavior, then test whether a template, regional default, or bounded policy solves it. Prefer a reusable constrained layer over global arbitrary configuration. Pilot in that market before generalizing.

Follow-up 5: When should you remove a configuration option?

Consider removal when sustained use is near zero, maintenance and support remain material, the option duplicates another, or it creates errors and unexplained outcomes. Publish a migration path, identify affected tenants, offer a compatibility period and rollback, then verify that removal does not break a hard requirement.