Because it is so new, people often struggle with figuring out how Data Generative AI (D-GAI) can be integrated into their business. I recently wrote about what technical requirements you’ll need for automated reporting, but that’s only half of the equation. Assuming you’ve got a good use case for automated content, you still usually need to sell that use case within your organization. This conversation is typically driven by someone with a visionary mindset that is able to peer into the future to see how D-GAI can provide value. I’ve been very fortunate to work with a lot of forward-thinking people who have made big D-GAI projects happen.

On the flip side of the visionaries are the skeptics. They serve a valuable role too, of course, by making sure new projects pencil out for their organization. Those folks tend to want to take a baby step first, leading us into the tricky waters of building an MVP- Minimal Viable Product.

For the reasons I will lay out in this article, setting up a ‘test’ product, or a simplified version of automated content, can be quite difficult. While the first part of this article is going to focus on those difficulties, don’t worry- there ARE solutions to all of the problems I lay out. After reading this, you’ll have a guide showing exactly what speed bumps you are likely to encounter as you try to sell automated reporting internally, and how you can navigate around them.

An Automated MVP

The fundamental problem with building out an automated content MVP is that the process of building it is a very front-loaded affair. The vast majority of the work involved is in the setup, with much less work needed after it is off and running. In fact, manufacturing reports at scale shares a lot of similarities with manufacturing a physical product at scale.

Think about what goes into setting up a factory for mass production. First, you have to prepare a building site and secure access to raw materials. Then, you have to construct the building and set up the production line. Finally, you have to set up a distribution channel for the products you create. 

The process infoSentience follows for building new automated content follows a similar three-step process. First, we need to connect to your company’s data. This will give our reporting system the raw material it needs to tell the stories. Next, we need to build out all the specific intelligence that’s required to really tell the story of your data. Just like setting up a production line, this is usually the most complicated part of the process. Finally, we need to set up some system to distribute the automatically written content to the end users.

All of this takes quite a bit of up-front time and expense. To build all of this out for a test period of content delivery would be like building an entire car factory just to build a few prototype cars. It’s simply too much of an investment to undertake up front to pencil out. 

The Too-Minimal-To-Be-Viable Product

When faced with this dilemma, a response that I often hear from potential clients is something like: “let’s just do a simple version of the product”. While I understand their thought process when they make this suggestion, it isn’t a viable way to sell the solution internally. The problem with creating simplified versions of the final reports is that it will likely end up being a “Mad-Libs” style solution, in which a template is set up and filled in with data. I wrote an entire article about why these reports don’t work, but the basic problem is that the narratives are always reporting on the same basic things, so they don’t really provide any insight (and are often just plain boring). Internal skeptics viewing examples of these reports will quickly realize that either: (1) the reports are so simple that they are not very valuable, or (2) such simple reports could pretty easily be created internally if they really want them.

Going back to our car factory example, it would be like trying to sell somebody on the idea of building a luxury car by first building a small factory that produced a simple economy car. At that point, the buyer is going to need to make a ‘leap’ to understand how to go from the economy car that has been built to the luxury car that would be the final delivery.

Since we always show potential clients interactive examples of our best work, the creation of a simplified MVP merely changes the kind of ‘leap’ that they will need to make. After showing them a demo of our best work, internal skeptics need to go from:

After building a simplified MVP they need to go from:

Personally, I think the second leap is actually more difficult, and so creating a simplified version of a final product can actually set us back in selling the product internally.

Three Solutions

Human-Written Examples + Trust

I mentioned previously that nobody builds a factory just to produce a few prototypes. The good news is that we don’t have to build a factory to build a prototype. Just like in the automobile industry, we can hand build a prototype for review. In the D-GAI space, this involves getting a representative sample of your data, determining exactly the kinds of narratives we can automatically build, and then hand-writing examples for your review. We can then easily iterate with clients to ensure the narratives look exactly how they want them. 

Building a manually written narrative isn’t enough by itself, however. You have to have faith that the prototype narratives can be turned into automated reports that look just like the prototype. This is where having a long history of producing quality content comes into play. At infoSentience, for instance, we’ve been creating automated content for more than 10 years, so we know exactly what’s possible when looking at a data set.

Rev-Share/Bounty Models

Instead of having to sell the higher-ups at your organization on the value proposition of automated reporting, you may be able to set up a revenue-sharing or bounty-based contract. This has the effect of outsourcing the value question to us. We have to make a determination if the final product will likely make back the costs of development, and if so, we choose to go forward. This arrangement also incentivizes us to make continual improvements to increase the value of the contract.

Finally, this structure often makes it simple to expand the original product, as the initial rev-share model can apply to the new content. Essentially, your automated content provider is just turning on a money faucet, and the only question is how much more money is going to come out. 

You’re a Giant

If the value of the automated content is significant enough, it may be the case that a ‘trial’ run is more than enough to cover the costs of setting up the product. Even a three-month trial period might be sufficient in certain cases. In this situation, the MVP is the full product, and you therefore don’t need to worry about making a long-term commitment up front. This is even more likely to be the case if the content itself requires less work to set up. 

In Conclusion

Ultimately, any new business decision is going to require seeing into the future and making your best assessment of how to proceed. When that future assessment involves working with a new vendor and utilizing a new type of technology, looking into that vendor’s past is often the best guide. In infoSentience’s case, we’ve had a 10+ year history of building great products for leading companies in several verticals. When you combine that experience with the MVP alternatives laid out in this article, you should have confidence in moving forward with automating your reporting and content generation.