Let's talk about data products for a second—especially the kind built by internal data teams who are now tasked with externally-facing product innovation work. You know, the kind of prodouct that outside people have to pay to use. (You've had it pretty nice so far: those internal stakeholders? They have been getting paid all this time to use your solutions—regardless of quality 😉

In short, I think the work is much harder, and you'll face a lot more struggles particularly if you're in a large enterprise used to rigid processes, is risk-averse and "default-no" to almost every change you seek to introduce, or has a culture that demands assurances, but believes itself to be nimble and innovative.

That is a HARD environment to create impact in—but hey, you're smart and like a challenge right?

Here are 10 ideas I hope you'll be aware of as you jump in the pond (welcome, the water is beautiful but no lifeguards on duty!). These are true whether it's a platform, an AI solution, or traditional analytics SAAS/solution:

1. You had a handful of stakeholders in the past; now you have 1000s of prospects. This wider pool of prospective customers can seem inviting at first, until you realize how unique individual users are and how much noise each opinion can put into your product backlog—if not managed properly.
2. You'll need to do a lot more user research to understand just as much what NOT to do vs. what TO do—because the opinions will be many, you can't build everything, and there is an opportunity cost when you build the wrong thing.
3. You will have to transition to an outcomes-mindset, particularly early in the journey—and realize that irrational buyers buy on emotion, even when it comes to data products. If you have a technical background, this will be a hard shift to make, particularly if 90% of your effort goes into product and technical development—and the remaining 10% goes into design, marketing, sales, etc.
4. You may think your job is to build a data-driven insights solution, and you may resist heavily when the market says "we want this thing over here - can you do that?" "Over there" may be a viable product, but your team will miss it if they think "our job is to make ML models, pipelines, the platform  or ______" (insert another output format). The key insight? Letting go of what you believe would, should, or could benefit the customer as a data product—and instead, accepting the reality of that their words and actions are telling you. This is really hard if you're an expert in _____ and they're not really interested in that—as your identity may feel in question, and while it's not personal, it sure feels that way.
5. You will likely realize that the design and UX of the solution—particularly if it is technical—will quickly become relevant unless you're doing something so groundbreaking and revolutionary that customers are willing to tolerate high levels of initial complexity and difficulty to reap the value you promise. The thing is, shortly after you show traction, you may find a competitor is on your heels without the technical debt, and with a UX and proposition that is so crystal clear and simple. That CLI interface might have seemed so powerful until a competitor's app comes out and all the sudden, non-technical users can also get value out of the data and insights.
6. If you're in a big, slow, wealthy enterprise, you're probably in a culture that does not support innovation (even if they have a department with that name that hasn't been shut down yet). "The culture" wants to avoid risk, and follow processes—things that don't pair with agile product development. Most of the people are there to "follow the process"—outcomes and results are somebody else's problem with a higher pay grade. To counter this, you may need to imitate the grit and flexibility of startup culture -- flexible teams who love the customer problem, take on the role that is needed by the business and users, and are relentlessly focused on establishing product/market fit. The challenge is trying to work inside the culture, while also resisting it when it is at odds with the startup mindset you may need to bring a commercial product to market. On the plus side, you may also have a lot of assets on your side (a salary for one!) and the clout, marketing/branding, and internal enablement/resources that a startup does not.
7. You may find it hard to adapt to the creative work required when you're building something new. The feedback that says "no thanks." The silence you get when trying to even get feedback on your ideas. The rejection.
8. You'll soon realize that getting people to commit to paying you you monthly or annually for your data-driven solution is a lot harder unless the value is crystal clear—and relevant, right now. You'll be confused when they aren't super excited the very first time you tell them about your baby and ask to set up a call—wondering why they don't see the "obvious" value that your team does. The wise product leader welcomes the challenges, pushbacks, complaints, and feedback—because it's all ammo to make a better product with greater impact. It's just information—not judgement—and it's certainly better than silence.
9. You won't realize that a lot of "product" happens after your ship the first thing; not before. Launches get way overblown; the launch is the beginning not the end.
10. If you're technical, and your buyer is "on the business side," you'll learn the hard way why the design/UX, product, and positioning is so critical — even if the solution is intended for a technical audience. The actuaries may think your new "risk calculator" is unbelievable, but the CIO is the one writing checks—and they're still not sure what's wrong with the way they already do risk calculations.

Look: if you got this far, and have been tasked with making your first commercial data product, somebody already believes in you or your team.

The kicker is that you may need to let go of "data is the solution," your technical training, and some of your analytical skills that aren't as useful when we're in the creative process.

You know what a bad technical strategy looks like when you see it—the thing with data product creation is that the data part and the product part require different skills. You are likely going to be biased towards the former. The latter can be sloppy, fast, unpredictable, messy, and sometimes irrational—but that may be the environment you'll need to play in for awhile if you want to build indispensable data products people will pay for.

Photo by Jack Ward on Unsplash