Intuit Developer
Partner Program

Phase 1: Research

Featuring:
  • Strategic direction
  • Customer research and interviewing
  • Data synthesis and consolidation

Challenge: A developer program beyond technical API access did not exist, and data around what partners wanted and needed from us was largely unknown or unvalidated assumptions.

Hypothesis: If we create a compelling collection of benefits that resonate with the needs of growth for the holistic partner organizations, we will see an increase in the quality of integrations and partner applicants, and a increase of QuickBooks user connections to these partner's solutions.

Summary

(NOTE: This is a 2-part portfolio piece. Part 1 is the research, definition, and program prototyping. Part 2 is the design, development, and deployment of the touchpoints.)

Context: QuickBooks is the world's leading bookkeeping and accounting software for small and medium businesses, and a core part of that success is the 3rd party integration ecosystem (as seen in the apps.com example). This ecosystem is supported by the customer-facing integration marketplace Apps.com, and the developer-facing Intuit Developer Portal, seen below.

The customer of this project is the 3rd party business looking to bring their app or integration to the QuickBooks ecosystem.

Left: Apps.com public site. Right: Intuit Developer API Portal

Problem our customers were facing: The developer portal only supported technical needs for API documentation and help resources. To grow and succeed beyond technical implementations, the developer customer needed more support, but nothing existed beyond the technical resources. As a result, partners had limited options for growth, and the QuickBooks user had a reduced breadth of available, high-quality integrations.

Business objective: Extend the benefit to developer customers by meeting their growth and success needs beyond the technical platform capabilities, and create an offering that will increase the quality and quantity of new partners applying to the program, which in turn increases the benefit Intuit can offer to the QuickBooks user in the app marketplace.

This project's primary customer: The stakeholders at 3rd party partner companies who are building and marketing their integrations.

The ask from Intuit: For us to research, evaluate, propose, and build a tiered partnership program as a collaboration between the Intuit Partner Management team and the Intuit Developer Platform team (my team).

Role: Design strategist and principal designer
Team: Developer Platform and Strategic Partners
Research

Part 1: Deep customer empathy

The state of understanding of the developer partners' needs outside of the API was sparse and undocumented. We couldn't charge forward because we didn't know who we were serving on a qualitative, empathetic level.

Taking a step back and finding the "Jobs to be Done"

We already had quantitative data on our partners, but little qualitative. The method I chose was a "Jobs to be Done" style interview with a variety of partner customers, believe it would give me deep, high-resolution insights through the human interaction and conversational exploration. A "thick data" (deep with few) approach.

Deep qualitative "Jobs to be Done" interviewees (2 not pictured)

The interview format was adapted from the JTBD "switch" interview. The questions gave room for the participants to go deep into their motivations, emphasizing exploration and introspection. Some questions from the interview:

When do you first remember considering becoming an Intuit Developer Platform partner? What prompted this consideration?
What problem did you see being solved by this partnership? And, has the partnership fulfilled that promise?
Was there a “last straw” moment you remember that gave you the final nudge to engage with Intuit?
Before you experienced the relationship Intuit, what do you remember what you hoped you would end up with? And having experienced it, how does the reality compare to the hope?

The interviews were meaningful conversations that allowed for the deeper motivations behind wanting to use our platform and API to be revealed. After finding the overlap between interviews, three key findings rose to the surface:

  1. Partners place a heavy emphasis on the relationship between them and us, believing an active relationship to be critical to their success.
  2. They believe they require qualitative guidance and quantitative feedback for their integrations to excel in the platform ecosystem.
  3. The widespread brand-equity of Intuit is one of the biggest attractors.

Armed with this clear, but broad, direction on the deeper needs of our customers, it was time to narrow in on specifics. For that, I turned to a co-creative activity in Mural where the customers would help design the solution themselves.

Part 2: Go broad then go narrow

With the assistance of our Partner Management and Developer Platform stakeholders, we collected a broad list of benefits Intuit could offer to our partner customers. The list was of things we already do and things we could potentially do but aren't.

Finding resonance through co-creation

I had the idea of using Mural as a co-creative space for the customer to design the tiered benefit program alongside us. An activity was created where 9 general categories of benefit would be stack-ranked by importance to the participant, and then the individual benefits would be sorted into tiers based on the participant's input.

The activity started with this Mural of the 9 categories and 80~ benefits, with the invitation to add ad-hoc as needed:

The starting state of the co-creative activity

We wondered if sorting nearly 100 items over the course of an hour could be done. Our participants proved that not only could it be done, but that by having them drive the activity they were able to reach a confident end-state in an average of 40 minutes!

The process looked like this (this is a 36 minute time-warp):

The results were surprising and pleasing

We conducted 20 of the activities, allowing a wide variety of partners types (company size, maturity, industry) to each contribute their own vision of what a meaningful tiered partner program looked like to them.

There was a concern that the output would be biased toward customers wanting everything available in the entry tier, but participants were all cognizant of the downsides of asking for something unreasonable vs. something realistic, even if they moved benefits they wanted into tiers they currently did not qualify for based on the model.

Pivot point: Interviewees adding new groupings

After a few sessions, we found that interview participants kept adding their own ad-hoc items that all had to do with performance analytics of their intergrations. We added this new category and options for the remainder of the sessions and it was one of the most used. A blind spot was identified and remedied.

Adding a layer of quantitative data via large-scale survey

To help bolster the quantitative value of the customer input, we also sent a version of the activity to several thousand partners via a survey. The aggregated survey response further validated our hypothesis about partner benefit and gave us a solid foundation of data to move forward.

Highlighted skills
Synthesis

Turning data into direction

With a wealth of net-new insights, I turned the qualitative into quantitative be creating a simple spreadsheet function to distribute and weight the importance and grouping of sorted data from the co-creation activities.

Script to created a weighted ranking of importance from participants

This gave us a blended "voice of the customer" which we considered the core collection of "needs" across the platform.

But, it was still only information, not direction. We had confidence in what the customers "needs and wants" but that didn't mean it lined up with that core constraint of "what can Intuit deliver" as noted in the next pivot point:

Pivot point: Overriding customer wants

As much as we want to please everyone, the constraints of business have to be respected. ROI, scalability, sustainability, and risk had to be taken into consideration. Some things everyone wanted had to be de-scoped so we could delivering holistically for an entire platform.

Applying the internal filter of constraint and scope

With the directional data and knowledge of our constraints, we re-did the activity with internal subject-matter experts to come up with a pilot version of a program, mixing customer wants/needs with organizational capacity/reality to create a proposed solution that could be delivered in a sustainable and scalable way.

The fastidiously created internal version using research and constraints to find a middle-ground.

Which was further "mocked up" by me and a team mate in a spreadsheet that would represent the expression of the program and tiers:

Spreadsheet where the program tier benefits were prototyped and validated.

After validating this "prototype of a program" with our external participants, we felt like we had more than enough confidence to declare the abstract definition of our tiered partner program defined.

With a solid foundation on what was going to resonate and meet the needs of our customer, it was time to turn it into a public-facing touchpoint to drive the interest of new partners, as well as re-incentivizing existing partners to renew their energy.

Highlighted skills

Reflections & learnings

Starting from a blank slate of knowledge had advantages and disadvantages. To move quickly, we needed something that would cut through assumptions and be a tie-breaker when it came to indecision. The Jobs to be Done interviews provided a set of guiding principles about whose needs we are serving. The first phase of research galvanized a new understanding of our customer across the broader team.

The co-creations sessions provided a whole new kind of insight past the interviews, however. By allowing the customer to co-create and talk aloud with us, context and insight was discovered that I would not have known to explore were it just an interview. By allowing for hands-on input from the customer, we reduced our own assumptions by bringing the source right into the project. Even though the customers aren't experts on how to design a tiered partner program, they were experts on their own needs and expectations.

Continue the journey in Part 2: Build and launch →