Does jobs-to-be-done packaging work for a horizontal data platform?
The company I work for is Placer.ai ($100M+ ARR). We’re a location intelligence platform that sells our data across a number of different verticals (Retail, CRE, local government, Financial Services, Advertising, etc.). Given we’ve built a data platform that has a wide variety of use cases, my hypothesis is that JTBD packaging is not a good fit for our business. We could focus on a few of the jobs that are more common among our customers, but we have dozens of long tail jobs that our customers use our data for.
I’d like to explore packaging that isn’t designed around the JTBD, but instead tries to differentiate using features and/or thresholds that generally align with value. For example, things like SSO, admin consoles, premium support, access to our data across more geographies (e.g. states), etc. could all be features of more premium tiers.
I know many believe JTBD packaging is a best practice, which I would agree with for many SaaS companies, but I don’t think it works well for companies like ours. I’m curious if anyone else shares this perspective or do you believe that there’s always a way to design packages around JTBD?
Thanks!
Steve
1 Like
I’d like to offer a slightly different perspective, based on my experience across three horizontal platforms, including accounting software, which I think offers a useful analogy.
As you might expect, an accounting platform serves a broad range of customers with very different setups and a long tail of unique use cases.
The key is not to try to package for every possible job, but to focus on the most critical clusters, those that drive the most revenue or demonstrate the clearest willingness to pay. For example, an inventory management module might be a high-value “job” across industries like manufacturing and retail. If you find that a job resonates broadly, you can then collaborate with Product to deepen the capabilities and build toward fuller end-to-end use case packaging.
Without some anchor in customer jobs, it’s easy to slip into feature-driven packaging, which is simpler to construct internally but often misses how customers perceive and value the offering. A quick test: if you pursue a feature-based approach, can you name and position the packages clearly, without them sounding overly generic or technical?
In short, I’ve found that jobs-to-be-done framing actually simplifies packaging decisions on a horizontal platform, allowing you to group customers by intent rather than industry.
Would love to hear your thoughts or reactions to this!
1 Like
Steven,
I recommend building value models for each industry vertical because the value of he data will vary depending on the customer use case.
Happy to talk more about that if you are interested. I can point you some resources.
Ed
1 Like
@Andrew_Yee I really appreciate your perspective! I think your example is a good one. I’d argue ours is an even more difficult platform to design JTBD packaging for because not only is our data used across several industries, but it’s also used across several functions. I assume an accounting platform is sold primarily to one function.
- I’m curious, were you able to fit ~80% of your revenue into 3-5 core JTBD?
- A platform, by definition, is more general purpose in nature supporting lots of use cases. Was there an evolution at the companies you mentioned where the platform started as something more generic then solutions were built on top of it?
- For jobs that your platform may support but you decided not to build a package around (long tail use cases), how did you handle those buyers? Did you have some sort of general purpose package or were those typically customers that you didn’t have good product market fit for so you tried not to sell to them all together?
2 Likes