Jun 30
Over-committing into a corner (Part Two)
In my last post, I referred to the team prioritizing a white labelled SDK feature that we did not have sufficient resources on hand to develop for, as well as needing to deploy the feature while the customer was mid-integration. While it may already seem self-explanatory on avoiding the premise altogether, it helps to reflect on the situation to glean productive lessons for the future.
Be certain on what is being promised
We’ve already acknowledged that the customer is midway into the integration process. As a result, we need to be absolutely sure that the key requirements match the customer’s expectations. Unfortunately, I’ve seen situations where we think we have collected requirements only to have the customer try out the nearly-completed iteration and and realize it’s significantly enough counter to their expectations. In this respect, we need to err on the side of over-communicating to ensure that the team and the customer are in tandem. We got this far with the customer and we really don’t want to delay this any more than we need to.
Engage internal support teams
Technical support teams can be a source of important information especially if they have interacted with the customer in question. The developer(s) on the customer side handling the integration may have contacted our technical support team with their questions and expectations around how the proposed feature should work. That customer feedback could be interpreted by the technical support team in a way that other internal teams (e.g. engineering) may not have thought through. This interpretation later could be converted into key requirements validated by the customer.
Don’t promise production-ready results from the first iteration
Considering we were developing the SDK as a brand new feature, there were bound to be issues and edge cases not fully thought through. As a result, we need to clarify with the customer that the new feature is in a “beta” phase still to be improved. We also need to shore up the notion that the team and the customer are a partnership to further improve the new feature. If we can set expectations like that, it’ll go a longer way to maintaining the relationship towards continually improving the feature.
While it’s great to have customers who are eager to use your product, product managers have a responsibility to both internal customer-facing teams and the customer themselves to set expectations as early as possible. When we do so, we have flexibility to handle the customer’s use-case and examine a fuller breadth of options to make sure both parties are successful. To the extent that we can, the product manager needs to think steps ahead, otherwise we might find our hands tied unexpectedly.
