How To Build an Add-on Step 2: Listen

Before we started building our add-on, we spent some time listening. We did two things:

  1. Read Harvest’s API documentation and did some basic prototyping. It’s easy to paint yourself into a corner if you don’t know the limits of the integration you’re building.
  2. Met with a group of Harvest users to discuss what their needs are. People don’t always know exactly what they want, but it’s worth finding out what they think they want! We plan to measure and learn from how people behave as well but that comes later.
Sitting down over coffee to listen to Harvest usersI don’t believe in trying to be too clever when asking people questions. Simple, open-ended questions are the most useful to me. Here’s what we asked.

Q. What brought you here today?

This is helpful to know for the next time we do this. “Fear” seemed to be the big motivator and “Pain” was a close second. This helps us to understand what is going through people’s “lizard brain” when they consider our add-on. As I understand it, the lizard brain is the very instinctive part of our brain that heavily influences decision-making. (For a very long explanation of what the lizard brain refers to, check out Rory Sutherland’s talk on Praxeology. Lizard brain shows up at 22min but it’s worth watching the whole thing)

All of these people knew of us beforehand. It will be interesting next time to see what kind of participation we get.

Q. What contracts and forms do your customers sign?

This question is intended to reveal use cases, and it ferreted out several that we hadn’t considered. Great! It also confirmed our suspicion that, in addition to estimates, Harvest users tend to ask clients to sign a Services Agreement (a Master Services Agreement, Services Agreement or Contract, depending on who you ask). This is great for us, since handling all these contracts in one place offers value above and beyond the simple integration.

Q. What contracts and forms do your vendors sign?

The intent of this question is the same as the previous question, just considered from a different angle. What we confirmed here is that a contract’s format (electronic, paper, …blood?) is chosen by the vendor and gets pushed down the channel – not the other way. This is a useful insight for us when we model Inkdit’s network effect.

Next we anchored the discussion by describing some of the integration possibilities that we identified after reading Harvest’s documentation:

  • Synchronizing Clients
  • Provisioning Accounts
  • Automated Workflows for Invoices and Projects

By showing some examples, we kickstarted the creative energy we were hoping for from our guests. We showed examples and then let people talk. This was where we spent the bulk of our time together.

It was fascinating to see the similarities and differences in the how each company went from quote to finished project. As we had hoped, patterns emerged, and some of these aligned with possible integrations.

We also did a bit of fishing to see if there were product enhancements to Inkdit that they would find useful. Specifically, we were wondering about common boilerplates and forms, the templates that people reuse, that they would find useful if they were available in Inkdit. We’ve tossed a few of their suggestions up on GitHub as Gists.

Q. If we only listed one feature of an integration on our landing page, what would be the one that would make you say, “I want to try this!”

This was my favorite question. The answers here are what do the most to guide the development and the marketing of the add-on. Overwhelmingly, the answer was, “The ability to attach a contract to an estimate.”

After we thanked our guinea pigs and went back to the office, we had a meeting about what we’d learned. We sketched out a basic plan of action, and started some longer thought-processes.

TIP: Record everything! One of the smartest things we decided to do was to invite our friend Idris. He’s a writer, blogger and he has a background in recording. He captured everything for us and I’ve revisited those records many times since.

Next in the series How To Build an Add-on Step 3: Write Code