Throw Your Vendor an RFI Curveball

Ask them how they'd solve for your objectives

Inspired by David Raab and his recent newsletter Don’t Misuse Proof of Concept in System Selection since he referenced use cases in the manner of Clayton Christensen’s “Job to be Done.” I took it a step further a few years back and used Strategyn’s Outcome-Driven Innovation method in a similar situation.

A number of years ago I was continually dropped into strategy projects that needed someone who had experience on both the business side, and the technology side. The challenge was that these projects had already run through half their budget because the strategy team was a) trying to use up as much utilization as possible, and b) thought they could fake IT knowledge.

In these situations, I didn’t have the luxury of rescheduling stakeholder meetings in order to pull out the information I needed from them. I was usually given a file dump, and would certainly have a chance to lead some of the discussions going forward. Unfortunately, I had to tread lightly in order to avoid friction with the client, and also making sure I didn’t shine the wrong light on the team members that preceded me.

Don’t accept their version of the current state

Sometimes you have to learn by reading, because there isn’t always a mentor around when you need one. I was brought into a billion dollar automobile distributor to find ways to improve their incentive management capability. As I mentioned above, I was not able to go backwards, so I had to capture the necessary information, and organize it very quickly.

I learned a nice little technique a long time ago (from a book) called Relationship Mapping. I was able to sit down with one of the key people in the Incentives Management team and within 30-45 minutes built a catalog of every every piece of information that flowed through this group. That’s literally all the time I had. The end result looked something like this:

One of the other things I learned (in another book) to do was probe, and verify. You need to ask “where does the information go to next?” And follow up with “where does it really go to?” You’ll often find that little details get paved over because it becomes invisible over time. You need to shake it out sometimes.

While the transport mechanism was not depicted above (only the format), always ask how something gets from supplier to customer, and then ask “how does it really get there?” Even if you’re designing a new future, you need to understand where you’re starting from to migrate these things successfully.

From a visual perspective, I laid it out like this:

Don’t accept “their” requirements based on the “their” version of the current state

To save money, this particular client documented their current state processes and then developed future requirements against them. That pre-supposes that the future state will remain unchanged from a process perspective. But that’s generally not a good practice to follow. In fact, these sort of requirements exist in the solution-space, so they tend to point toward a particular technology and/or the limited understanding of current options by the client.

Since there was no budget to conduct a thorough study, I only had two things I could do. First, I would use a job mapping technique derived from Outcome-Driven Innovation (ODI) to create a logical proxy for the future-state process. Next, I would develop a logical set of metrics, map them to the requirements that were defined for me (where possible), and validate as much as possible in a two hour future-state workshop which was pre-scheduled, and I was not leading (and any other meetings I had).

Yes, I had two days to prepare! Phew!

So, I was not writing requirements, I was actually creating customer needs statements that the requirements would trace back to; just like testing scenarios trace back to user stories. The twist here is that this would be used to develop a Request for Information (RFI) and platform vendors would be invited to respond.

Elaborating Jobs, Steps, and Outcomes

This was not going to go over well with vendors, “I thought to myself.” Having responded to RFI’s and RFP’s in the past, I knew that having a set of canned responses to common questions is critical since the win-rate (and margins) for these horrible things is usually very low. So, you don’t want to spend much time on them, if possible.

I’m not going to go into a lot of detail, but let me give you a flavor for what I came up with.

Create a proxy for the future-state

During the brief interview that I mentioned above - and with the help of a file dump - I was able to capture enough information to also construct an ODI-style Job Map. While there are many things I would do different today, I was limited in time and and resources to pull from.

Essentially, the goal was to map out the sub-objectives of incentives management that supported their ability to Offer Dealer Incentives (their core objective) in which their dealers could enroll.

I would probably rename the job as well. But those are conversations for another time.

Note, there are no specifics about how anything is done, only what must be accomplished - the perfect framing for your “use case.” You’ve already seen what a high level “how” map looks like up above, and I left things out! This is much simpler, and something you can walk a client through and confirm “Are you trying to accomplish this?” and “OK, let’s talk about how you know you’ve done it successfully.”

We’re trying to automate the consumption chain

No one wants solutions that require our constant attention. So, it’s always useful to illustrate where the opportunities for improvement to the existing process exist. I only throw this in here to provide a bit more detail than the relationship map I illustrated. Much of that information had to be elaborated into work products like the one below as a reference guide for value gains.

There were many opportunities to design seamless integrations, workflow automation, business rules and also decision-support (possibly through machine learning). While discussing this with the client, I never introduced the concept, or language of Jobs-to-be-Done, and the Outcome Metric language was simplified for client (and potential vendor) consumption.

My job wasn’t to educate people on yet-another-method (YAM). 😁 It was to solve a problem for them. They just wanted answers - and probably wouldn’ve been happy getting the answer on day one!

Did you notice that nothing was automated above? Sometimes the right kind of flowchart drives a point home. There are only two steps that are value-creating, and the goal is to eliminate everything else (if we can). There was a lot of opportunity staring us right in the face.

Ask Vendors to Provide Purpose-driven Responses

I’ve taken you on somewhat of a winding road. I’m going to assume that all of you know what Use Cases look like, what User Scenarios look like, etc. But I would throw a curve ball at vendors. After all, you’re about to make a huge investment, and you need to know if they are going to be a help, or a hindrance with regard to getting your job done.

In this case, we needed to know that a) the vendor had domain knowledge, b) that their domain knowledge was in line with ours domain objectives, and c) that their platform could support all of the critical activities quickly, efficiently, and successfully. We simply didn’t want a “sure, we have that feature” response from them.

You need an internal scoring model for each question

This can be established in a meeting or workshop setting internally. Keep in mind that most of the metrics (your needs, not requirements) will not have much relevance for frequency since they don’t discuss a how something is done. Importance and Satisfaction / Frustration is probably enough to rank these metrics for inclusion in an RFI, and also a ranking mechanism to evaluate vendor responses relative to that internal ranking.

Presenting it to a Vendor

Keeping in mind that the model is comprised of logical steps - which represent sub-objectives supporting the Job-to-be-Done - my suggestion would be to break each step in the model out into it’s own section and do something like this depiction of Step 1:

Note: there would be more elaboration to provide the appropriate contexts. These are simple examples.

When we enroll dealers in our incentive program, we are looking for a solution that helps us to…

• identify all of the qualified dealer candidates as quickly as possible. How would we do that with your platform?

• ensure that all enrollment candidates are aware of our program. How would your platform help us to communicate and monitor that?

• locate at-risk enrollments and quickly understand / execute an effective resolution? How would you help us do that?

These statements don’t need be in metric language when your asking someone how they would solve for it. And it doesn’t matter if they understand your scoring criteria. In fact, if as a team, you have de-prioritized a step, or metrics within the step, you don’t have to include those at all.

Step 2 might look like this:

When we decide on the incentive design approach, we are looking for a solution that helps us to…

• Gain access quickly to competitor program performance data for the time periods required, e.g., JD Powers. How would your platform accommodate this?

• Quickly understand the competitor program performance data and act on it effectively and efficiently. How would your platform help us?

• Etc.

Step 14 might look like this:

When we monitor program performance, we are looking for a solution that help us to…

• quickly capture, understand, and act upon historical performance data, e.g., cost, take rates, etc. Please tell us how your platform would accommodate this.

• make sure we don’t overlook actionable negative performance trends

• make sure that we can quickly detect performance variances and understand their root cause

• Etc.

These sorts of asks from a vendor will probably require them to think a little bit harder than the typical RFI because we’re not asking them to show us a feature, or a component. We’re asking them to solve our problems. If they respond in a meaningful way, then you know they are serious about helping you to achieve your business goals, and not just theirs. It should be very simple to select those that you believe can actually demonstrate such capabilities.

If you’d like to see another example of a model and related outcome metrics, you can follow my posts as I build out the Market of Marketing. I will ultimately show a full set so it will be simple (if you agree with the model) to use it as a basis for a marketing platform selection tool.

Let me know if I can help.

---

If you enjoy my blog, I hope you’ll share it with a colleague. I’ve made it REALLY easy.👇