#AgileDataDiscover weekly wrap No.5

TL;DR

 Let’s get into it!

#AgileDataDiscover weekly wrap No.5

GTM: Houston we have a problem

While we have worked in the Data Domain for over 3 decades we are fairly new to the Product Domain. There are a bunch of product patterns we have not found or used. Defining a Go to Market approach feels like one of those.

Do we go SLG, PLG, CLG, ELG? Are there other LG’s we haven’t found? Are these LG’s strategies, patterns or tactics (and do I need to care about the distinction?)

How do tactics like Freemium fit into it, assuming you can only apply a Freemium tactic when you are using a PLG motion, is this true? Is Freemium a tactic?

While we have strong opinions, can make a decision and can self justify how we made it, this build in public process is as much about the learning as the outcome. There must be patterns we can use to help us decide our GTM. Let’s explore patterns that are available.

There must be patterns we can use to help us decide our GTM

We spent a short a short amount of time searching Google and browsing the Reforge templates, but in the end reverted back to the help of the LLM, this time ChatGpt to help us with the steps required to define a GTM strategy. To keep these weekly wraps as brief as possible, the detail on this is in our substack here. 

We know our target market is any organisation that has a legacy or current data platform and no adequate documentation for it, which is a bit broad. Will need to refine this market a lot more as we get deeper into validation using the MVP.

For personas we have identified three main data personas that we think the AgileData Disco product will help: a Head of Data, a Data Governance Manager and a Data Consultant. All of these of course have various different roles and titles depending on the organisation they work for. Funnily enough only the Data Governance Manager is a new persona for us, so there is a risk that I have brought in a bunch of bias for these, time will tell.

The Unique Value Proposition current draft is:

For the Head of Data (or Data Governance Manager or Data Consultant)

Who needs to discover, document and understand their current Data Platform so they can rebuild it or augment it. The AgileData Disco is a Product wich automagically discovers and documents a data platform, producing actionable outputs in less than one hour. Unlike the current manual task that takes multiple people multiple months, the AgileData Disco Product will:

– Accept multiple input files

– Output multiple pattern templates that are actionable

– Not require a direct connection to the data platform

– Provide outputs that can be stored offline

Let’s review our GTM channel options 

One of the benefits of building in public and these posts, is the writing forces us to clarify our thoughts. It helps take the jumble and try and make some sense of it. 

When I think about the channel options I think about three patterns. First, we are great at building, ok at selling, crap at marketing. So I naturally levitate towards Product Led Growth and Growth Marketing, it seems like the nirvana option.

This would require us to make #AgileDataDisco a no touch SaaS product. We would auto provision, which is ok, we have a pattern for that already. Sign-up is ok, we use Google Identity Manager for this already.

Onboarding would be a lot less complex than the full AgileData capability, we would have a simple flow of uploading a file (query log etc), pick your output types (Information Product Canvas, Conceptual Model, Data Dictionary etc) and then hit generate and voila!

We would need to build out the subscription management, but we would use a SaaS subscription management solution for that and integrate it, rather than build our own. That would still leave the marketing problem (unless we hit the magic viral nirvana from listing on Product Hunt which is unlikely). As we are bootstrapping we don’t have the dolleros to spend big on ads and outbound email spam (which we wouldn’t do anyway)

Second, we are already building out an AgileData Network of Consulting partners around the world. We have learnt that providing them with a Swiss Army knife selection of things they can offer their customers, over and above the Fractional Data Service has value. For example the ability to offer the AgileData Courses to their customers. We could add AgileData Disco to this toolkit so they would be the only people who can use it.

When I talk to new potential partners one of the most common questions (after how much) is who finds the new customers. This GTM pattern means that effort still sits with them.

Which takes me onto the third pattern. We offer Agiledata Disco using a freemium pattern. Same work to be done as the PLG pattern, but we limit how much of the product a customer can use and if they want to carry on, we pass them over to an AgileData Network partner. This approach would be good for us and the partner, not sure how a customer would feel about it. I need to test that. Of course it doesn’t solve our fiscal marketing constraint. So I am no closer to a decision on this one.

Next let’s think about the pricing options. 

Pricing options

Here is when the chicken and the egg pattern hits again, without defining the GTM channel it’s going to be difficult to define a pricing strategy. A key Product Management pattern for pricing is to focus on the value delivered to the customer not the cost it takes to deliver it.

While being profitable is important, we are bootstrapping and so need to be profitable as we don’t have VC funding to spend money while bleeding money, Nigel Vining and I want to build a sustainable business we can run for 20 years not a “growth engine” we can flick quickly and move on to the next shiny thing.

Our core values and our vision leads us to a pricing model that means we make good money, but fair money. We will probably leave money on the table with this approach but I am ok with that.

With that in mind lets list the options we could use to charge for AgileData Disco.

• Pay per token used
• Pay for a set of tokens in advance
• Pay per input uploaded
• Pay per input used
• Pay per output created
• Pay each time its run to produce an output
• Pay a fixed monthly fee

 We tested these with the leader of a data team asking what their preferences was for paying for the outcomes AgileData Disco delivers, they responded with:

1. Pay per output
2. Pay for a bunch of tokens in advance
3. Pay per token used
4. Pay each time it is run to produce an output

#1 & #4 seem to align in my head with our current Channel led GTM and #2 & #3 seem to align with a PLG GTM. But I think I am just making shite up with those mappings.

So no closer to a decision.

Product market fit is wow

As in wow that is seriously frickin cool, not as in Ways of Working.

For AgileData we have a simple sales message.  It will cost you at least $600k per annum in salaries for a data team. We (and our AgileData Network Partners) will deliver that as a Fractional Data Team for $60k a year. You will also need to pay for a bunch of data technology, data collection, data storage, transformation tool, catalog etc, and then all the ongoing storage and compute costs to run that technology.  We provide all that in the $60k (yes you read that right, that includes the storage and the compute costs, we pay for it not you)

You will be amazed at the lack of wow we get from this sales message. I have been socialising the AgileData Disco prototype and outputs a lot over the last 30 days.

We am constantly hearing people say wow.

And then they do one of two things. They say, the prototype didn’t automagically create it, did it? You did some manual turking to produce that. To which we demo uploading a query log from a BI tool, hitting generate and a few minutes later showing them the output. Seeing is believing. Or they stop and think, and then they come back with a use case they could apply it to right now.

We think that wow…. So that is what Product Market Fit looks like.

Keep making data simply magical