I have heard that 80% of features go unused in mature B2B products by most customers. Then inevitably, people conclude that 80% of their effort was wasted on building features people don’t use - and we should do a better job managing our products etc, etc. Seems simple enough. Of course, there is truth to that; however, I have a product I recently signed up for (b2b SaaS product) that I plan only to use 20% of the capabilities of for the foreseeable future. BUT it gives me comfort that it CAN do a lot more things that I might want in the future - and that legitimately impacted my buying decision. Sometimes that 80% matters even when it’s not being actively used - or atleast it does to me.
I'm sure that's true, and probably true in everything. You probably wear 20% of your clothes 80% of the time; restaurants probably mostly serve 20% of their menu; etc etc. So I suspect part of the answer to all of this is just, "that's how the world works."
This brings to mind a marketing principle. I call it "selling an idea vs. the real thing" but there's probably a more academic term. I often use the auto industry as a parallel:
- SUV makers advertise their cars off-roading
- Sports car makers advertise 0-60 and track times
- Family car makers show cars full of kids and friends, etc.
Most consumers will just use the car to commute and go to the grocery store. But the idea that your car could go off-road or set a record time at a racetrack is the appeal. You're buying the idea rather than the actual functionality you'll use.
In the enterprise software context, buyers get won over by the capabilities that a software could do because they want the Ferrari, Land Rover, etc. When the buyer isn't the user, their mindset is something akin to, "Wow look at the amazing things my team could do with it." Then they cut implementation project spend and resourcing, get a basic MVP running, and move on to the next problem rather than continuing to increase value from the tool. This leads to only the bare features being used.
Yeah, I think there's definitely something to that. At least in the software case, I do think that most people *think* they'll use those things, whereas people who buy SUVs probably know they'll drive them through the arctic like they do in the commercials. But I think there's a real appeal to knowing you're buying something that *could* do it.
1. The Linux/Unix culture of small tools that can pipe to each other on the cmd line is by far more productive then the monolitic Windows OS applications that communicate with copy and paste. True Window has a cmd line and bash utilities but enterprise IT Windows users find them a corner case.
2. There is something to be said for validation of a data product at a Fortune 500 company. Unfortunately this is often overused in PR. When I made a comment about product X being used at France Telecom - a friend said "Big deal FT uses everything". Often poorly.
Fortune 500 companies buy everything since they are a group of global business units. The unit in Singapore may not know or care what the unit in SF is doing. It might be better in software PR to focus on the product owner in a company than the size of the company itself, and how it contributes to productivity and how the ROI is measured.
3. The beauty of Snowflake is that you can get started with almost zero-knowledge in <15'. DBT cloud is much more demanding in that respect - to make an unfair comparison, there is a lower energy barrier to use awk, bash and SQL in a data pipeline than monolithic tools.
4. We were looking at FeatureForm for feature engineering and storage and it looked great. But - there were too many things to configure and manage - so we passed.
5. At Intel we had a process for evaluating new systems and it was based on the RFP model. Open source and Linux change that - to the point where an engineer can develop an excellent system without capital expenditure and outside. the Intel capital aquisition process.
There are cases of systems developed in local fabs that were adopted by corporate. Not many but it proves that low affordable solutions, even DIY when engineered and well-crafted will win out over the big box software
It’s the DIY stuff that seems most telling to me. In my view, part of their success comes from them being very targeted, but part of it also comes from a commitment to use the thing. People are invested in the tool; someone usually wants to build the tool; someone feels better about their career if other people use the tool. These tools get pushed to their limits, much more so than a tool that people go out and buy.
Which isn’t to say that we should build everything. It’s more that there’s something in how those tools get built that promotes much deeper adoption than the tools we buy, and it seems like there’s something to learn from that.
I wonder if you hit the nail on the head near the end there: buyers want flexibility/optionality and avoid vendor lockin but to achieve that you end up with a worse product experience. Maybe that’s why now you have these data stacks that try to wire multiple tools technology in the chain but allow you to choose what goes where but much harder to do that in a polished way where everything has to work with everything. I have a longer thought here around there being too many categories right now in “modern data stack” and we will see consolidation in the horizontal layers (let’s say transformations + orchestration) but then within each of the layers you’ll have multiple “winners” that just play nicely with the other layers (think multiple BI tools but they all need to support Snowflake, Redshift, Big Query, etc).
The fiefdoms of sorts make sense to me, where winners basically just play nice with winners (or with their chosen ecosystem)and everyone else gets squeezed out. I think I've said this somewhere else before, but we got in this world where every vendor really wanted to market themselves as playing nice with everyone, and being equal partners to all, and all of that. I think that'll give way to a lot more ruthless partnerships, where people have more preferred partners so that they can narrow the set they integrate with and all of that. And that seems like it'd reinforce itself, because customers would choose those tools.
(And I agree with you that people probably *want* to avoid lock in, though I really think that's more often than not actually harmful, and customers would be better off if they embraced it. They won't, or at least startups won't, so, oh well.)
That echoes my experience. When I was running the eng team at TripleLift I was very wary of lockin and intentionally avoided adopting proprietary tools. Part of it was due to lack of conviction but bigger part was trying to maintain optionality. I do think that benefited us while we worked through things but as we got larger it just made sense to lean in - now the company is heavy on a lot of the AWS vertical solutions and exploring both the proprietary Snowflake and Databricks solutions. At that point you're sort of locked in already and might as well go all in to get more of the performance/cost benefits even if it doesn't feel good. On the flipside you do see a big push to open source - Databricks did Delta Lake and now Snowflake with Iceberg so who knows. Maybe that's more of a nod to the openness knowing many companies won't actually leverage it.
I suspect a common scenario is you're small and you only encounter one problem at a time so you pick the solution to solve that problem. Over time you end up with a web of solutions and only in hindsight do you realize that you should have picked a single, opinionated vendor. Yet if you're big you already have a solution that sort of works and the cost of switching is just too high and you're happy with the devil you know.
That last point makes sense to me. Someone else mentioned that the better buffet analogy is that we constantly walk into a buffet wanting one thing, so we end up piecing together a meal as we're hungry for each course.
No individual in the family cares about the cohesiveness of the Office Suite, because they aren't prioritizing family operational efficiency, but instead they're just focused on their own lives. (Except for dad, who set up all the family accounts one Saturday night, and son, who hacked all screen limits on Sunday.)
It reminds me in other ways of the innovation token metaphor (https://mcfunley.com/choose-boring-technology). Basically, as a manager / lead / etc., you only get a couple "innovation tokens" you can use. For everything else, you ought to make the boring choice, which is whatever the industry standard is.
For me, an all-in-one-platform is rarely going to warrant a precious innovation token, because it doesn't often unlock something that isn't available by some other more standard/boring way. To call out the example of "hacking together development workflows on top of dbt environments and zero copy clones" vs. using "Y42 virtual data builds" -- you've really got to be convinced that Y42 has nailed the trajectory that your platform is going to evolve to invest in that vision, vs. keeping things flexible, boring, and hacky.
So on the first point, there was a footnote that got cut about that, that the other explanation to all of this is the family doesn't actually want any of this: The dad wants to stay away from his kids and the mom hates the dad and the teenager is trying to look at thirst trap videos on tiktok without his parents knowing. Which I think is probably kinda true for families? Though I don't think that part of the analogy would really extend to data stuff that clearly.
On the innovation points, I think that, 1) still kinda raises the question as to why not doing it a hacky way is innovative? It's work, sure, but it doesn't strike me as something that feels worthy of an innovation token. In some ways, it's actually less innovative, because I think one of the traps that companies get into is they always re-evaluate new stuff. If you say, we're using this one tool, and we are using it for the next 5 years, you might get a little innovative in how you use it, but the scope of that innovation is like, we read the entire manual, rather than, we check product hunt for some shiny new thing every week.
And 2) I think that's still an argument for telling more stories? Because the story is what makes it clear that investing is ok, it's boring and right to do it, etc.
(The counterpoint to all of this, I guess, is that we're just muddling through forever, and muddling through is best done with a bunch of hacks anyway, so just do the hacks. Which, ok, I can see that.)
Oct 3, 2023·edited Oct 3, 2023Liked by Benn Stancil
Yeah, I'm more of the muddling-through mindset. Because if the team gets pretty good at muddling, then you can do a lot of things good enough to get by, and you save your innovation tokens (and money) for new products that you can't muddle through. Because the value prop for all-in-one approaches is only there if they really can provide everything necessary, because as soon as you do the "all-in-one... plus one other custom thing", the value prop gets thrown off.
That half makes sense to me. The muddling philosophy vs set everything up perfectly on Office makes sense. But I think that's a different than all in one vs best of breed. My feeling is that a lot of products aren't all in one per se, but can do a lot more than the one thing we use them for. So as it related to tooling, it's not a tradeoff between best of breed vs all in one; it's a choice we make to muddle with new stuff we constantly change, vs trying to push the muddling with the existing stuff a lot further. (Though again, that's a different question than muddling vs planning and all that.)
I wanna think on this for a few days since I sit on the other side of the table building said all-in-one experiences that no one uses ...
But one image pops up in my head that won't let go... my microwave. Companies have spent countless R&D dollars on stuff like sensor cooking and other features to innovate a device from the 50s... but probably the biggest innovations were the express 1,2,3 minute buttons, and the +30sec button ...
But, that said, it seems like we both never use the other features, *and* complain about problems they could solve? We keep burning the popcorn with our +30 second button. Why don't we try to push the popcorn button? Maybe we do, or maybe the popcorn button doesn't work that well, and the whole premise is wrong? I don't know. It's not a unique thing to data tools though, so perhaps this is just life, and this whole post is some obvious and universal truth that I'm wandering into like a stoned college sophomore, pretending to have thought of something novel.
Well that weird "it's the same, but wait it feels a bit different too" sorta why the idea keeps sticking in my head. data tools aren't fully consumer-ized goods that are idiot-proofed for the lower common analyst. We inherently distrust (probably rightfully) any product that promises that. But we also don't want to go back to days of "here's a pile of HDFS and workers, go"... and finding that sweet spot between the extremes is where we're awkwardly flailing around.... I think.... I dunno. need to spin this in my head more
(As an aside, there's a really interesting question in there about who you build for as a vendor. We struggled with this at Mode, where our default was to build for people who were very capable, independent, etc, and I think that works at first. But it's hard to really scale that. You can, and some companies/brands/content people pull it off. But it's hard, and it pulls a lot of companies towards the lower common user, I suspect.)
Building on top of OSS might be the right balance of supportability and extensibility. Feature requests can be built in-house and contributed back to the community. Or just pay the vendor money to prioritize them.
I'm sure people have written hundreds of books on this, but OSS (for products, not frameworks) seems like something that always sounds like a best of both worlds: You get a general foundation for free, and you can customize it exactly how you want! And then in reality it's the worst of both worlds: You use software that's not really supported and has rough edges, and to make it work you still have to build it all yourself.
hey everyone - my name is Hung and I'm the product lead and founder at Y42. Thank you Benn for using Y42 as an example in your current post. While it's gratifying to hear that you acknowledge Y42's potential, it's also a sobering reminder of the challenges we face in fully realizing that potential.
From Y42's inception almost four years ago, we've been driven by an obsession to create a product that data teams would love. Although we believe we've accomplished this, I must admit that I underestimated the effort needed to re-educate the market about the benefits of a tool like Y42.
The best products don't always win. The data community is yet to fully appreciate the benefits of version controlling code and data to eliminate expensive rebuilds of tables, or the efficiency of an integrated solution in debugging, cataloging, and monitoring data pipelines.
One of your thoughts that particularly struck me was: “They can't force their customers to invest in making the most of their products.”
I think we all know that it’s not always the case that user behavior is strongly dictated by the interface - that's part of why we talk about “user stories" or "user paths" when we develop products! So I believe that we need to teach our users best practices in ways that are non-intrusive, simple and memorable. As we've closely mirrored best-in-class UX tools like Notion and Linear to bring the same level of finesse to Y42, we're now focusing on adding out-of-the-box automations and guardrails that can help you get the most out of Y42.
Re-educating the market may be an uphill battle, but we're ready for it. Our challenge now is to ensure that your positive future projection comes true by clearly communicating the benefits and features of Y42, and providing proactive customer engagement to help users fully utilize what Y42 offers.
If you're willing to commit and have faith, Y42 can provide a unified, reliable space to build, monitor, and maintain your data flow with an unrivaled user and developer experience.
I really like the imagery of walking into the restaurant and stopping at the appetizer station and never fully exploring the full buffet. Totally!✊
I have heard that 80% of features go unused in mature B2B products by most customers. Then inevitably, people conclude that 80% of their effort was wasted on building features people don’t use - and we should do a better job managing our products etc, etc. Seems simple enough. Of course, there is truth to that; however, I have a product I recently signed up for (b2b SaaS product) that I plan only to use 20% of the capabilities of for the foreseeable future. BUT it gives me comfort that it CAN do a lot more things that I might want in the future - and that legitimately impacted my buying decision. Sometimes that 80% matters even when it’s not being actively used - or atleast it does to me.
I'm sure that's true, and probably true in everything. You probably wear 20% of your clothes 80% of the time; restaurants probably mostly serve 20% of their menu; etc etc. So I suspect part of the answer to all of this is just, "that's how the world works."
Ya - and I think the psychology applies to clothes and food as well actually...
80-90% of all product features - desktop and server are unused.
This brings to mind a marketing principle. I call it "selling an idea vs. the real thing" but there's probably a more academic term. I often use the auto industry as a parallel:
- SUV makers advertise their cars off-roading
- Sports car makers advertise 0-60 and track times
- Family car makers show cars full of kids and friends, etc.
Most consumers will just use the car to commute and go to the grocery store. But the idea that your car could go off-road or set a record time at a racetrack is the appeal. You're buying the idea rather than the actual functionality you'll use.
In the enterprise software context, buyers get won over by the capabilities that a software could do because they want the Ferrari, Land Rover, etc. When the buyer isn't the user, their mindset is something akin to, "Wow look at the amazing things my team could do with it." Then they cut implementation project spend and resourcing, get a basic MVP running, and move on to the next problem rather than continuing to increase value from the tool. This leads to only the bare features being used.
Yeah, I think there's definitely something to that. At least in the software case, I do think that most people *think* they'll use those things, whereas people who buy SUVs probably know they'll drive them through the arctic like they do in the commercials. But I think there's a real appeal to knowing you're buying something that *could* do it.
As usual good thinking.
A few comments:
1. The Linux/Unix culture of small tools that can pipe to each other on the cmd line is by far more productive then the monolitic Windows OS applications that communicate with copy and paste. True Window has a cmd line and bash utilities but enterprise IT Windows users find them a corner case.
2. There is something to be said for validation of a data product at a Fortune 500 company. Unfortunately this is often overused in PR. When I made a comment about product X being used at France Telecom - a friend said "Big deal FT uses everything". Often poorly.
Fortune 500 companies buy everything since they are a group of global business units. The unit in Singapore may not know or care what the unit in SF is doing. It might be better in software PR to focus on the product owner in a company than the size of the company itself, and how it contributes to productivity and how the ROI is measured.
3. The beauty of Snowflake is that you can get started with almost zero-knowledge in <15'. DBT cloud is much more demanding in that respect - to make an unfair comparison, there is a lower energy barrier to use awk, bash and SQL in a data pipeline than monolithic tools.
4. We were looking at FeatureForm for feature engineering and storage and it looked great. But - there were too many things to configure and manage - so we passed.
5. At Intel we had a process for evaluating new systems and it was based on the RFP model. Open source and Linux change that - to the point where an engineer can develop an excellent system without capital expenditure and outside. the Intel capital aquisition process.
There are cases of systems developed in local fabs that were adopted by corporate. Not many but it proves that low affordable solutions, even DIY when engineered and well-crafted will win out over the big box software
It’s the DIY stuff that seems most telling to me. In my view, part of their success comes from them being very targeted, but part of it also comes from a commitment to use the thing. People are invested in the tool; someone usually wants to build the tool; someone feels better about their career if other people use the tool. These tools get pushed to their limits, much more so than a tool that people go out and buy.
Which isn’t to say that we should build everything. It’s more that there’s something in how those tools get built that promotes much deeper adoption than the tools we buy, and it seems like there’s something to learn from that.
I wonder if you hit the nail on the head near the end there: buyers want flexibility/optionality and avoid vendor lockin but to achieve that you end up with a worse product experience. Maybe that’s why now you have these data stacks that try to wire multiple tools technology in the chain but allow you to choose what goes where but much harder to do that in a polished way where everything has to work with everything. I have a longer thought here around there being too many categories right now in “modern data stack” and we will see consolidation in the horizontal layers (let’s say transformations + orchestration) but then within each of the layers you’ll have multiple “winners” that just play nicely with the other layers (think multiple BI tools but they all need to support Snowflake, Redshift, Big Query, etc).
The fiefdoms of sorts make sense to me, where winners basically just play nice with winners (or with their chosen ecosystem)and everyone else gets squeezed out. I think I've said this somewhere else before, but we got in this world where every vendor really wanted to market themselves as playing nice with everyone, and being equal partners to all, and all of that. I think that'll give way to a lot more ruthless partnerships, where people have more preferred partners so that they can narrow the set they integrate with and all of that. And that seems like it'd reinforce itself, because customers would choose those tools.
(And I agree with you that people probably *want* to avoid lock in, though I really think that's more often than not actually harmful, and customers would be better off if they embraced it. They won't, or at least startups won't, so, oh well.)
That echoes my experience. When I was running the eng team at TripleLift I was very wary of lockin and intentionally avoided adopting proprietary tools. Part of it was due to lack of conviction but bigger part was trying to maintain optionality. I do think that benefited us while we worked through things but as we got larger it just made sense to lean in - now the company is heavy on a lot of the AWS vertical solutions and exploring both the proprietary Snowflake and Databricks solutions. At that point you're sort of locked in already and might as well go all in to get more of the performance/cost benefits even if it doesn't feel good. On the flipside you do see a big push to open source - Databricks did Delta Lake and now Snowflake with Iceberg so who knows. Maybe that's more of a nod to the openness knowing many companies won't actually leverage it.
I suspect a common scenario is you're small and you only encounter one problem at a time so you pick the solution to solve that problem. Over time you end up with a web of solutions and only in hindsight do you realize that you should have picked a single, opinionated vendor. Yet if you're big you already have a solution that sort of works and the cost of switching is just too high and you're happy with the devil you know.
That last point makes sense to me. Someone else mentioned that the better buffet analogy is that we constantly walk into a buffet wanting one thing, so we end up piecing together a meal as we're hungry for each course.
I totally agree on this - and this is a nice read on the subject. https://open.substack.com/pub/analyticsengineeringroundup/p/becoming-pangea?r=28kfy3&utm_medium=ios&utm_campaign=post
No individual in the family cares about the cohesiveness of the Office Suite, because they aren't prioritizing family operational efficiency, but instead they're just focused on their own lives. (Except for dad, who set up all the family accounts one Saturday night, and son, who hacked all screen limits on Sunday.)
It reminds me in other ways of the innovation token metaphor (https://mcfunley.com/choose-boring-technology). Basically, as a manager / lead / etc., you only get a couple "innovation tokens" you can use. For everything else, you ought to make the boring choice, which is whatever the industry standard is.
For me, an all-in-one-platform is rarely going to warrant a precious innovation token, because it doesn't often unlock something that isn't available by some other more standard/boring way. To call out the example of "hacking together development workflows on top of dbt environments and zero copy clones" vs. using "Y42 virtual data builds" -- you've really got to be convinced that Y42 has nailed the trajectory that your platform is going to evolve to invest in that vision, vs. keeping things flexible, boring, and hacky.
So on the first point, there was a footnote that got cut about that, that the other explanation to all of this is the family doesn't actually want any of this: The dad wants to stay away from his kids and the mom hates the dad and the teenager is trying to look at thirst trap videos on tiktok without his parents knowing. Which I think is probably kinda true for families? Though I don't think that part of the analogy would really extend to data stuff that clearly.
On the innovation points, I think that, 1) still kinda raises the question as to why not doing it a hacky way is innovative? It's work, sure, but it doesn't strike me as something that feels worthy of an innovation token. In some ways, it's actually less innovative, because I think one of the traps that companies get into is they always re-evaluate new stuff. If you say, we're using this one tool, and we are using it for the next 5 years, you might get a little innovative in how you use it, but the scope of that innovation is like, we read the entire manual, rather than, we check product hunt for some shiny new thing every week.
And 2) I think that's still an argument for telling more stories? Because the story is what makes it clear that investing is ok, it's boring and right to do it, etc.
(The counterpoint to all of this, I guess, is that we're just muddling through forever, and muddling through is best done with a bunch of hacks anyway, so just do the hacks. Which, ok, I can see that.)
Yeah, I'm more of the muddling-through mindset. Because if the team gets pretty good at muddling, then you can do a lot of things good enough to get by, and you save your innovation tokens (and money) for new products that you can't muddle through. Because the value prop for all-in-one approaches is only there if they really can provide everything necessary, because as soon as you do the "all-in-one... plus one other custom thing", the value prop gets thrown off.
That half makes sense to me. The muddling philosophy vs set everything up perfectly on Office makes sense. But I think that's a different than all in one vs best of breed. My feeling is that a lot of products aren't all in one per se, but can do a lot more than the one thing we use them for. So as it related to tooling, it's not a tradeoff between best of breed vs all in one; it's a choice we make to muddle with new stuff we constantly change, vs trying to push the muddling with the existing stuff a lot further. (Though again, that's a different question than muddling vs planning and all that.)
I wanna think on this for a few days since I sit on the other side of the table building said all-in-one experiences that no one uses ...
But one image pops up in my head that won't let go... my microwave. Companies have spent countless R&D dollars on stuff like sensor cooking and other features to innovate a device from the 50s... but probably the biggest innovations were the express 1,2,3 minute buttons, and the +30sec button ...
I'm obligated to agree with the analogy... https://benn.substack.com/p/the-annual-microwave-conference
But, that said, it seems like we both never use the other features, *and* complain about problems they could solve? We keep burning the popcorn with our +30 second button. Why don't we try to push the popcorn button? Maybe we do, or maybe the popcorn button doesn't work that well, and the whole premise is wrong? I don't know. It's not a unique thing to data tools though, so perhaps this is just life, and this whole post is some obvious and universal truth that I'm wandering into like a stoned college sophomore, pretending to have thought of something novel.
Well that weird "it's the same, but wait it feels a bit different too" sorta why the idea keeps sticking in my head. data tools aren't fully consumer-ized goods that are idiot-proofed for the lower common analyst. We inherently distrust (probably rightfully) any product that promises that. But we also don't want to go back to days of "here's a pile of HDFS and workers, go"... and finding that sweet spot between the extremes is where we're awkwardly flailing around.... I think.... I dunno. need to spin this in my head more
(As an aside, there's a really interesting question in there about who you build for as a vendor. We struggled with this at Mode, where our default was to build for people who were very capable, independent, etc, and I think that works at first. But it's hard to really scale that. You can, and some companies/brands/content people pull it off. But it's hard, and it pulls a lot of companies towards the lower common user, I suspect.)
Building on top of OSS might be the right balance of supportability and extensibility. Feature requests can be built in-house and contributed back to the community. Or just pay the vendor money to prioritize them.
I'm sure people have written hundreds of books on this, but OSS (for products, not frameworks) seems like something that always sounds like a best of both worlds: You get a general foundation for free, and you can customize it exactly how you want! And then in reality it's the worst of both worlds: You use software that's not really supported and has rough edges, and to make it work you still have to build it all yourself.
Reminds me of the xkcd on standards https://xkcd.com/927/
hey everyone - my name is Hung and I'm the product lead and founder at Y42. Thank you Benn for using Y42 as an example in your current post. While it's gratifying to hear that you acknowledge Y42's potential, it's also a sobering reminder of the challenges we face in fully realizing that potential.
From Y42's inception almost four years ago, we've been driven by an obsession to create a product that data teams would love. Although we believe we've accomplished this, I must admit that I underestimated the effort needed to re-educate the market about the benefits of a tool like Y42.
The best products don't always win. The data community is yet to fully appreciate the benefits of version controlling code and data to eliminate expensive rebuilds of tables, or the efficiency of an integrated solution in debugging, cataloging, and monitoring data pipelines.
One of your thoughts that particularly struck me was: “They can't force their customers to invest in making the most of their products.”
I think we all know that it’s not always the case that user behavior is strongly dictated by the interface - that's part of why we talk about “user stories" or "user paths" when we develop products! So I believe that we need to teach our users best practices in ways that are non-intrusive, simple and memorable. As we've closely mirrored best-in-class UX tools like Notion and Linear to bring the same level of finesse to Y42, we're now focusing on adding out-of-the-box automations and guardrails that can help you get the most out of Y42.
Re-educating the market may be an uphill battle, but we're ready for it. Our challenge now is to ensure that your positive future projection comes true by clearly communicating the benefits and features of Y42, and providing proactive customer engagement to help users fully utilize what Y42 offers.
If you're willing to commit and have faith, Y42 can provide a unified, reliable space to build, monitor, and maintain your data flow with an unrivaled user and developer experience.
I have posted my thoughts on my LinkedIn page as well - feel free to join the discussion: https://www.linkedin.com/posts/hung-dang-y42_the-potential-gap-activity-7117174621174423552-IW1c?utm_source=share&utm_medium=member_desktop