Let's talk about data products for a second—especially the kind built by internal teams who are now tasked with externally-facing product innovation work. You know, the kind that outside people have to pay to use. (Yes, your internal clients 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, moves at a snail's pace, and has a culture that demands assurances but loves to call itself nimble and innovative.

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!):

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 regret not having a dedicated product manager (DPM) who understands that it is outcomes, not features, that customers want—and that an endless backlog of user stories and features never gets done. The DPMs coming from product marketing will have a lot to learn about building a product; the ones from product/engineering will have a lot to learn about market positioning and balancing what they think people need vs. what people want to buy.
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." An overly analytical, "I know how they should be approaching this with data" mindset will prevent you from seeing opportunity when it may be right in your face.
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. The culture wants to avoid risk, and follow processes—things that don't pair with agile, product development. While you have some benefits such as your benefits(!), a salary, and cushion, you may lack the grit and flexibility of startup culture -- teams of like-minded individuals 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 -- even if it's not part of the original plan. Taking your internal processes and culture and forcing it on a team focused on external product innovation is likely adding a tax, not a benefit. Risk? Get ready for it - there are no promises in the space of innovation.
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. 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.
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, 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