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.
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
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).
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.
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 ...
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.
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.
The potential gap
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.
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
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).
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.
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 ...
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.
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