TRUE

true

A unified ecosystem with convenient asset transfer between networks is an ideal the crypto space has been chasing for a long time. However, because blockchains have varying token standards and consensus mechanisms, this feat is (currently) only achievable via bridges. The path to Bitcoin (BTC) on Ethereum, Ether (ETH) on the Binance Smart Chain (BSC), Solana (SOL) on Ethereum, and so on runs through a bridge. At the time of writing, DeFiLlama estimated the total value locked (TVL) across all bridges at around $27.79 billion. These are good numbers. But when put in context, they highlight that perhaps, despite the widespread desire for an interoperable crypto ecosystem, bridges are not as widely utilized. Out of the $2.5 trillion of value in the crypto market, only about 0.01% is utilized across chains. This is an indication that not many crypto users are utilizing bridges. And according to Sher, CEO of Zecrey Labs (the team behind Kontos Protocol), a big part of this is down to the user experience. The solution, he says, lies in bridge abstraction. The ABCs of Bridging Crypto Assets The crypto space is not known for its user experience. Blockchain-based applications are typically more complicated to set up and use than regular apps, something that the average crypto bridge takes to the extreme. “The blockchain industry is often perceived as complex and difficult to navigate, especially for newcomers. Managing multiple wallets, handling private keys, and understanding gas fees can be daunting for users,” says Sher. It's not known exactly how many people use crypto bridges. What is known, however, is that for most users, the experience is anything but convenient. Crypto bridges tend to have unintuitive interfaces, with users often required to go through several steps to complete a bridge operation, which can take anywhere from a few minutes to several hours and attract significant fees. At the same time, the bridging scene is itself fragmented. Many bridging protocols only support a limited set of assets and blockchain pairs. “This means that currently, there are numerous bridges for different blockchain pairs, each with its own protocols and interface. Thus, users are regularly forced to use multiple bridges to get their assets on the target chain,” says Sher. When someone wants to interact with a chain like Avalanche, they typically need to address two aspects: Gas fees: They need to bridge AVAX tokens to Avalanche to pay for transaction fees (gas) on the network.


Other assets: They may also want to bridge other assets, such as stablecoins like USDT, to use within the Avalanche ecosystem. This dual requirement often means users must perform multiple bridging operations or use a service that can handle both aspects in a streamlined manner. The complexity of this process can be a barrier for some users, highlighting the need for more user-friendly bridging solutions. This is where bridge abstraction comes into play. What Is Bridge Abstraction? “The Bridge Abstraction Layer (BAL) is a structural design pattern that separates the abstraction (interface) from the implementation (underlying mechanics),” says Sher. “This decoupling allows for greater flexibility and independent development of both components.” Bridge abstraction builds on the concept of chain abstraction, where the aim is to hide the complexities of interacting with blockchains from the end user. When the user isn’t dealing with the specific details of underlying protocols, traditionally complex operations like cross-chain trading and asset transfer become straightforward. Abstraction essentially lets developers build cross-chain solutions without being tied to specific implementation details. According to Sher,  this translates to lesser involvement from the user during a bridging operation, as seen in Kontos’ design, which allows users to bridge across multiple chains via a single interface. Kontos is designed around the user’s intent. If someone intends to get tokens on a particular chain, they can do so using any assets they have on any chain(s). This is possible because the protocol lets users combine assets from various chains and move them to the target chain. It uses smart contracts and a network of participants to handle the complexities of gas estimation and payment behind the scenes. “Kontos' approach to gas abstraction represents a significant innovation in improving blockchain usability,” says Sher. ”By tackling this complex problem, Kontos is addressing one of the major pain points in blockchain interaction, potentially setting a new standard for user experience in the multi-chain ecosystem.” A New Standard for On-chain User Experience Bridge abstraction is a significant leap forward in simplifying interactions across blockchain networks. Users typically had to navigate complex processes when bridging assets, ensuring they had enough gas tokens on the source chain, selecting both the source and target chains, and managing specific assets across networks. With bridge abstraction, these barriers are minimized. Bridging no longer requires holding gas tokens on the source chain or keeping track of which chain assets are located. Instead, utilizing assets from multiple chains in a single task is possible. The system will calculate and optimize costs behind the scenes. This evolution promises a smoother, more intuitive on-chain experience that allows users to focus on their transactions rather than the intricacies of blockchain mechanics. It sets a new standard for blockchain accessibility and usability, paving the way for a more inclusive and user-friendly web3 ecosystem. A unified ecosystem with convenient asset transfer between networks is an ideal the crypto space has been chasing for a long time. However, because blockchains have varying token standards and consensus mechanisms, this feat is (currently) only achievable via bridges. A unified ecosystem with convenient asset transfer between networks is an ideal the crypto space has been chasing for a long time. However, because blockchains have varying token standards and consensus mechanisms, this feat is (currently) only achievable via bridges. The path to Bitcoin (BTC) on Ethereum, Ether (ETH) on the Binance Smart Chain (BSC), Solana (SOL) on Ethereum, and so on runs through a bridge. At the time of writing, DeFiLlama estimated the total value locked (TVL) across all bridges at around $27.79 billion. DeFiLlama DeFiLlama These are good numbers. But when put in context, they highlight that perhaps, despite the widespread desire for an interoperable crypto ecosystem, bridges are not as widely utilized. Out of the $2.5 trillion of value in the crypto market, only about 0.01% is utilized across chains. $2.5 trillion of value $2.5 trillion of value This is an indication that not many crypto users are utilizing bridges. And according to Sher, CEO of Zecrey Labs (the team behind Kontos Protocol ) , a big part of this is down to the user experience. The solution, he says, lies in bridge abstraction. Zecrey Labs Zecrey Labs Kontos Protoc ol Kontos Protoc , The ABCs of Bridging Crypto Assets The crypto space is not known for its user experience. Blockchain-based applications are typically more complicated to set up and use than regular apps, something that the average crypto bridge takes to the extreme. “The blockchain industry is often perceived as complex and difficult to navigate, especially for newcomers. Managing multiple wallets, handling private keys, and understanding gas fees can be daunting for users,” says Sher. says Sher. It's not known exactly how many people use crypto bridges. What is known, however, is that for most users, the experience is anything but convenient. Crypto bridges tend to have unintuitive interfaces, with users often required to go through several steps to complete a bridge operation, which can take anywhere from a few minutes to several hours and attract significant fees. At the same time, the bridging scene is itself fragmented. Many bridging protocols only support a limited set of assets and blockchain pairs. “This means that currently, there are numerous bridges for different blockchain pairs, each with its own protocols and interface. Thus, users are regularly forced to use multiple bridges to get their assets on the target chain,” says Sher. says Sher. When someone wants to interact with a chain like Avalanche, they typically need to address two aspects: Gas fees: They need to bridge AVAX tokens to Avalanche to pay for transaction fees (gas) on the network. Other assets: They may also want to bridge other assets, such as stablecoins like USDT, to use within the Avalanche ecosystem. Gas fees: They need to bridge AVAX tokens to Avalanche to pay for transaction fees (gas) on the network. Gas fees: They need to bridge AVAX tokens to Avalanche to pay for transaction fees (gas) on the network. Other assets: They may also want to bridge other assets, such as stablecoins like USDT, to use within the Avalanche ecosystem. Other assets: They may also want to bridge other assets, such as stablecoins like USDT, to use within the Avalanche ecosystem. This dual requirement often means users must perform multiple bridging operations or use a service that can handle both aspects in a streamlined manner. The complexity of this process can be a barrier for some users, highlighting the need for more user-friendly bridging solutions. This is where bridge abstraction comes into play. What Is Bridge Abstraction? “The Bridge Abstraction Layer (BAL) is a structural design pattern that separates the abstraction (interface) from the implementation (underlying mechanics),” says Sher. “This decoupling allows for greater flexibility and independent development of both components.” says Sher. Bridge abstraction builds on the concept of chain abstraction, where the aim is to hide the complexities of interacting with blockchains from the end user. When the user isn’t dealing with the specific details of underlying protocols, traditionally complex operations like cross-chain trading and asset transfer become straightforward. Abstraction essentially lets developers build cross-chain solutions without being tied to specific implementation details. According to Sher, this translates to lesser involvement from the user during a bridging operation, as seen in Kontos’ design, which allows users to bridge across multiple chains via a single interface. Sher, Kontos is designed around the user’s intent. If someone intends to get tokens on a particular chain, they can do so using any assets they have on any chain(s). This is possible because the protocol lets users combine assets from various chains and move them to the target chain. It uses smart contracts and a network of participants to handle the complexities of gas estimation and payment behind the scenes. “Kontos' approach to gas abstraction represents a significant innovation in improving blockchain usability,” says Sher. ”By tackling this complex problem, Kontos is addressing one of the major pain points in blockchain interaction, potentially setting a new standard for user experience in the multi-chain ecosystem.” says Sher. A New Standard for On-chain User Experience Bridge abstraction is a significant leap forward in simplifying interactions across blockchain networks. Users typically had to navigate complex processes when bridging assets, ensuring they had enough gas tokens on the source chain, selecting both the source and target chains, and managing specific assets across networks. With bridge abstraction, these barriers are minimized. Bridging no longer requires holding gas tokens on the source chain or keeping track of which chain assets are located. Instead, utilizing assets from multiple chains in a single task is possible. The system will calculate and optimize costs behind the scenes. This evolution promises a smoother, more intuitive on-chain experience that allows users to focus on their transactions rather than the intricacies of blockchain mechanics. It sets a new standard for blockchain accessibility and usability, paving the way for a more inclusive and user-friendly web3 ecosystem.

Bridge Abstraction - The Key to Unlocking True Blockchain Interoperability

My Top Ten Upwork Conspiracy Theories: True or False

Les meves deu millors teories de la conspiració: vertader o fals

Mis diez principales teorías de conspiración sobre Upwork: ¿verdaderas o falsas?

Kymmenen parasta salaliittoteoriaani: totta vai tarua

עשרת תיאוריות הקונספירציה המובילות שלי: נכון או לא נכון

私のトップ10のUpwork陰謀説：真実か嘘か

Менин мыкты он Upwork Conspiracy Theories: Чын же жалган

Миний шилдэг арван хуйвалдааны онол: үнэн эсвэл худал

Chunka Aswan allin Upwork Conspiración Teoríasniy: Chiqap utaq llulla

Cele mai bune zece teorii ale conspirației mele: adevărat sau fals

My Top Ten Upwork Conspiracy Theories: ሓቂ ድዩ ሓሶት።

En İyi On Upwork Komplo Teorim: Doğru mu Yanlış mı

Iithiyori zam eziPhezulu zokuSebenza kweNyelelo: Yinyani okanye bubuxoki

Table of Links Abstract and 1. Introduction Why ELIZA?
The Intelligence Engineers
Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs
From IPL to SLIP and Lisp
A Critical Tangent into Gomoku
Interpretation is the Core of Intelligence
The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion
Finally ELIZA: A Platform, Not a Chat Bot!
A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community
Another Wave: A BASIC ELIZA turns the PC Generation on to AI
Conclusion: A certain danger lurks there
Acknowledgements and References 4 Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs Beginning in 1950, almost exactly at the same time that Turing’s Mind paper appeared, there was an explosion in von Neumann/Turing style computer hardware. At that time, all of the existing computers, such as Colossus and EDVAC, were one-off machines. Although UNIVAC, the company spun off from Penn’s ENIAC project by Eckert and Mauchley, had promised a massproduced machine, none had yet been delivered when RAND decided to build the JOHNNIAC.[30] This was the machine on which Shaw, Newell, and Simon pioneered the IPL series of programming languages, which they used to implement what were are almost certainly the first real AIs: “IPL was first utilized to demonstrate that the theorems in Principia Mathematica which were proven laboriously by hand, by Bertrand Russell and Alfred North Whitehead, could in fact be proven by computation. According to Simon’s autobiography Models of My Life, this application was originally developed first by hand simulation, using his children as the computing elements, while writing on and holding up note cards as the registers which contained the state variables of the program. IPL was used to implement several early artificial intelligence programs, also by the same authors: the Logic Theorist (1956), the General Problem Solver (1957), and their computer chess program NSS (1958). Several versions of IPL were created: IPL-I (never implemented), IPL-II (1957 for JOHNNIAC), IPL-III (existed briefly), IPL-IV, IPL-V (1958, for IBM 650, IBM 704, IBM 7090, Philco model 212, many others.”[5] IPL introduced what became the most important concepts in classical Artificial Intelligence (and, in fact, in computing more generally), including list processing, symbolic computing (as foreshadowed by Ada Lovelace!), and recursion.[5] Notably, although Turing’s bombe, the code-breaking machine, was not a “modern” computer, in the sense that is was hardwired, as opposed to being of the von Neumann/Turing stored program type, the program that it ran was explicitly engaged in mechanical heuristic search, that is, in trying a huge number of operators (e.g., combinations of code keys) in a cleverly arranged order (e.g., beginning with the most probable), in hopes of reaching a goal (e.g., the key that would break the day’s code). Much later, Newell and Simon described heuristic search as a fundamental process of intelligence,[35], and remains one of the most important tools of AI.[2] However, IPL was an ugly programming language – not very far from assembly language – and, as an interpreted language it was slower than assembly or the soon-to-follow “high level” compiled languages such as COBOL and Fortran. These promised programmers both high performance and simplicity of expression. This brings us to SLIP and Lisp, which took different paths to bring simplicity and additional power to the important AI concepts pioneered in IPL. Author:
(1) Jeff Shrager, Blue Dot Change and Stanford University Symbolic Systems Program (Adjunct)( jshrager@stanford.edu). This paper is available on arxiv under CC BY 4.0 license. [2] Allen Newell once told me, in passing, that AI’s only had one tool, the ability to search huge multi-dimensional spaces efficiently, but that one tool is all you need. Table of Links Abstract and 1. Introduction Abstract and 1. Introduction Why ELIZA? The Intelligence Engineers Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs From IPL to SLIP and Lisp A Critical Tangent into Gomoku Interpretation is the Core of Intelligence The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion Finally ELIZA: A Platform, Not a Chat Bot! A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community Another Wave: A BASIC ELIZA turns the PC Generation on to AI Conclusion: A certain danger lurks there Acknowledgements and References Why ELIZA? Why ELIZA? The Intelligence Engineers The Intelligence Engineers Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs From IPL to SLIP and Lisp From IPL to SLIP and Lisp A Critical Tangent into Gomoku A Critical Tangent into Gomoku Interpretation is the Core of Intelligence Interpretation is the Core of Intelligence The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion The Threads Come Together: Interpretation, Language, Lists, Graphs, and Recursion Finally ELIZA: A Platform, Not a Chat Bot! Finally ELIZA: A Platform, Not a Chat Bot! A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community A Perfect Irony: A Lisp ELIZA Escapes and is Misinterpreted by the AI Community Another Wave: A BASIC ELIZA turns the PC Generation on to AI Another Wave: A BASIC ELIZA turns the PC Generation on to AI Conclusion: A certain danger lurks there Conclusion: A certain danger lurks there Acknowledgements and References Acknowledgements and References 4 Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs Beginning in 1950, almost exactly at the same time that Turing’s Mind paper appeared, there was an explosion in von Neumann/Turing style computer hardware. At that time, all of the existing computers, such as Colossus and EDVAC, were one-off machines. Although UNIVAC, the company spun off from Penn’s ENIAC project by Eckert and Mauchley, had promised a massproduced machine, none had yet been delivered when RAND decided to build the JOHNNIAC.[30] This was the machine on which Shaw, Newell, and Simon pioneered the IPL series of programming languages, which they used to implement what were are almost certainly the first real AIs: “IPL was first utilized to demonstrate that the theorems in Principia Mathematica which were proven laboriously by hand, by Bertrand Russell and Alfred North Whitehead, could in fact be proven by computation. According to Simon’s autobiography Models of My Life, this application was originally developed first by hand simulation, using his children as the computing elements, while writing on and holding up note cards as the registers which contained the state variables of the program. IPL was used to implement several early artificial intelligence programs, also by the same authors: the Logic Theorist (1956), the General Problem Solver (1957), and their computer chess program NSS (1958). Several versions of IPL were created: IPL-I (never implemented), IPL-II (1957 for JOHNNIAC), IPL-III (existed briefly), IPL-IV, IPL-V (1958, for IBM 650, IBM 704, IBM 7090, Philco model 212, many others.”[5] IPL introduced what became the most important concepts in classical Artificial Intelligence (and, in fact, in computing more generally), including list processing, symbolic computing (as foreshadowed by Ada Lovelace!), and recursion.[5] Notably, although Turing’s bombe, the code-breaking machine, was not a “modern” computer, in the sense that is was hardwired, as opposed to being of the von Neumann/Turing stored program type, the program that it ran was explicitly engaged in mechanical heuristic search, that is, in trying a huge number of operators (e.g., combinations of code keys) in a cleverly arranged order (e.g., beginning with the most probable), in hopes of reaching a goal (e.g., the key that would break the day’s code). Much later, Newell and Simon described heuristic search as a fundamental process of intelligence,[35], and remains one of the most important tools of AI.[2] However, IPL was an ugly programming language – not very far from assembly language – and, as an interpreted language it was slower than assembly or the soon-to-follow “high level” compiled languages such as COBOL and Fortran. These promised programmers both high performance and simplicity of expression. This brings us to SLIP and Lisp, which took different paths to bring simplicity and additional power to the important AI concepts pioneered in IPL. Author: (1) Jeff Shrager, Blue Dot Change and Stanford University Symbolic Systems Program (Adjunct)( jshrager@stanford.edu). Author: Author: (1) Jeff Shrager, Blue Dot Change and Stanford University Symbolic Systems Program (Adjunct)( jshrager@stanford.edu). This paper is available on arxiv under CC BY 4.0 license. This paper is available on arxiv under CC BY 4.0 license. available on arxiv available on arxiv [2] Allen Newell once told me, in passing, that AI’s only had one tool, the ability to search huge multi-dimensional spaces efficiently, but that one tool is all you need.

Newell, Shaw, and Simon’s IPL Logic Theorist: The First True AIs

If you’ve ever experienced a rush of satisfaction when a feature goes live, you’re not alone. It’s especially rewarding when you’re a user of your own product and see the feature working as intended. As a product manager, I know the feeling well–seeing a feature released and functioning smoothly can make me proud and lift my mood for the entire day. But have you ever wondered what’s behind that dopamine boost? Is it because our revenue has tripled?
Have we acquired thousands of new users?
Or perhaps received glowing feedback from our loyal customers? The truth is, that these outcomes often take time to materialize. The impact of a feature on our business and users might not be evident for weeks or even months. So, what exactly are we celebrating? This guide is for product teams who find themselves overly focused on outputs rather than outcomes. I’ll explore the psychological reasons behind the satisfaction of feature releases and offer strategies to shift our focus to what truly matters: outcomes. Our Brains Make Us Love Feature Factories If you’re unfamiliar with the term, a feature factory is, as ProductPlan describes it, “a business focused on building features rather than solving problems for customers.” Rather than concentrating on outcomes, this type of company prioritizes outputs. Although the drawbacks of feature factories have been discussed extensively, and product management has increasingly sought to avoid this pitfall, it’s still easy to fall into the feature factory trap. I believe there are at least three psychological reasons for this. Faster Gratification In psychology, two key concepts related to gratification are instant gratification and delayed gratification. Our brains are wired to crave instant gratification. As PositivePsychology puts it, “It’s a natural human urge to want good things and to want them NOW.” In contrast, delayed gratification involves resisting the urge for an immediate reward in favor of a more valuable reward in the future (Britannica). Although implementing and deploying a feature can take time and isn’t truly instant gratification, it still provides a sense of “faster gratification.” This is because the satisfaction of seeing a feature go live occurs sooner than observing significant improvements in business metrics. This preference for faster gratification drives teams to pursue quick wins, such as feature releases, even if these quick wins don’t contribute to long-term success. Being Invested As a member of a product team, you can become deeply involved in your work, developing a strong attachment to the features and projects you work on. This is especially true if you came up with the idea, contributed to the vision, and played a role in the design and implementation. It’s natural to feel proud and excited about releasing a feature you’ve put so much time and effort into. This strong investment can also lead to cognitive biases, such as the sunk cost fallacy. This fallacy describes our tendency to keep going with a project we’ve invested a lot in, even when it no longer makes sense (Asana). When we’re emotionally invested, it’s hard to let go, making it easier to push for a feature release and celebrate it. This attachment can also lead to confirmation bias, where we look for evidence that supports the feature’s value while ignoring signs that it might not actually meet users' needs. Tangible Results in a Digital World Features are one of the few “tangible” results in a digital world. Often, our work as product teams can feel disconnected from reality. We produce artefacts that only exist digitally, such as documents, prototypes, and mockups, which rarely have a real-world impact. It’s only when a feature is released that it becomes “tangible” and can make a real difference. Some people working on digital projects turn to hobbies like woodworking, painting, or furniture repair as a way to create something physical and see immediate results. Releasing a feature or improvement in your digital product offers a similar sense of tangibility. It’s something you can interact with and share with others, providing a visible and appreciated result. Why Feature Factories are Problematic Itamar Gilad provides a clear explanation of why the feature factory model is flawed. In a traditional factory, every unit produced creates value because it can be sold for profit. Thus, more output equals more value. While I don’t fully agree with the notion that “every unit produced creates some value” given my sustainability-oriented mindset, I understand his point. In software development, however, this doesn’t hold true. We often treat software development like a factory, but not everything we produce actually adds real value. In a feature factory, we end up with bloated, hard-to-maintain products featuring functionalities that few users find valuable. This mindset can lead to accumulating technical debt, reduced innovation, and growing user dissatisfaction. Over time, these issues compound, making it harder to maintain product quality, stifling creativity, and causing users to seek better alternatives. Ultimately, this can undermine a company’s competitive edge and long-term success. Recent trends in product management have introduced techniques like continuous product discovery and hypothesis validation, thanks to experts like Teresa Torres. Despite this, the 2023 State of Product Management Report by ProductPlan shows that feature factories remain a major challenge: 54% of roadmaps are designed around outputs, while only 44% focus on outcomes. The shift towards an outcome-oriented approach is slow and challenging. How to Move Away From the Feature Factory Mindset Understanding why we’re drawn to features is just the beginning. The real challenge is shifting our focus from outputs to outcomes. Our brains are wired to seek gratification and tangible results, making it difficult to detach from the products we work on. Even if we strive to move away from this mindset, our natural inclination to care about our work and seek immediate rewards remains. How can we use these brain biases to our advantage while shifting away from a feature-factory mindset? It all comes to making outcomes more tangible for your team and employing positive reinforcement based on outcomes. Here are the three key actions to take to shift away from a feature factory mindset. Firstly, during the planning stage, set specific, actionable goals that your team can directly influence. Rather than focusing on lagging indicators, aim for measurable product outcomes that can be impacted immediately by feature releases or improvements. Teresa Torres, in Continuous Discovery Habits, suggests setting product outcomes as goals because they reflect changes in customer behaviour that occur as soon as a feature is live. Additionally, ensure that metric tracking is readily accessible and emphasise its importance with regular team check-ins. Secondly, while it’s important to recognise the team’s effort in delivering features, celebrate their achievement of goals even more. Managers should provide strategic feedback that encourages an outcome-focused mindset and reinforces positive behaviours. Finally, engage more with users to understand how your work has affected their lives and share this feedback with your team, and potentially the entire company. This approach turns outcomes into tangible results through personal stories that resonate more deeply than raw data alone. To effectively shift away from the feature factory mindset, focus on setting clear, actionable outcomes, celebrate genuine value-driven successes, and continuously seek user feedback to align your team with what truly matters. Although the transition might be challenging, it will ultimately lead to a stronger team, better products, and overall company growth. Hey, I’m Valeria! Thanks for reading my article. This is my first piece for Hackernoon, and I'd love to hear your feedback. Here, I’ll be sharing insights on product management, product design, and sustainability, so stay tuned for more. See you in the next one! 👋 Feature image source: Canva AI Image Generator. If you’ve ever experienced a rush of satisfaction when a feature goes live, you’re not alone. It’s especially rewarding when you’re a user of your own product and see the feature working as intended. As a product manager, I know the feeling well–seeing a feature released and functioning smoothly can make me proud and lift my mood for the entire day. But have you ever wondered what’s behind that dopamine boost? Is it because our revenue has tripled? Have we acquired thousands of new users? Or perhaps received glowing feedback from our loyal customers? Is it because our revenue has tripled? Is it because our revenue has tripled? Have we acquired thousands of new users? Have we acquired thousands of new users? Or perhaps received glowing feedback from our loyal customers? Or perhaps received glowing feedback from our loyal customers? The truth is, that these outcomes often take time to materialize. The impact of a feature on our business and users might not be evident for weeks or even months. So, what exactly are we celebrating? This guide is for product teams who find themselves overly focused on outputs rather than outcomes. I’ll explore the psychological reasons behind the satisfaction of feature releases and offer strategies to shift our focus to what truly matters: outcomes . outcomes Our Brains Make Us Love Feature Factories If you’re unfamiliar with the term, a feature factory is, as ProductPlan describes it , “a business focused on building features rather than solving problems for customers.” Rather than concentrating on outcomes, this type of company prioritizes outputs. Although the drawbacks of feature factories have been discussed extensively, and product management has increasingly sought to avoid this pitfall, it’s still easy to fall into the feature factory trap. I believe there are at least three psychological reasons for this. ProductPlan describes it Faster Gratification In psychology, two key concepts related to gratification are instant gratification and delayed gratification. Our brains are wired to crave instant gratification. As PositivePsychology puts it, “It’s a natural human urge to want good things and to want them NOW.” In contrast, delayed gratification involves resisting the urge for an immediate reward in favor of a more valuable reward in the future ( Britannica ). PositivePsychology Britannica Although implementing and deploying a feature can take time and isn’t truly instant gratification, it still provides a sense of “faster gratification.” This is because the satisfaction of seeing a feature go live occurs sooner than observing significant improvements in business metrics. This preference for faster gratification drives teams to pursue quick wins, such as feature releases, even if these quick wins don’t contribute to long-term success. Being Invested As a member of a product team, you can become deeply involved in your work, developing a strong attachment to the features and projects you work on. This is especially true if you came up with the idea, contributed to the vision, and played a role in the design and implementation. It’s natural to feel proud and excited about releasing a feature you’ve put so much time and effort into. This strong investment can also lead to cognitive biases, such as the sunk cost fallacy. This fallacy describes our tendency to keep going with a project we’ve invested a lot in, even when it no longer makes sense ( Asana ). When we’re emotionally invested, it’s hard to let go, making it easier to push for a feature release and celebrate it. This attachment can also lead to confirmation bias, where we look for evidence that supports the feature’s value while ignoring signs that it might not actually meet users' needs. Asana Tangible Results in a Digital World Features are one of the few “tangible” results in a digital world. Often, our work as product teams can feel disconnected from reality. We produce artefacts that only exist digitally, such as documents, prototypes, and mockups, which rarely have a real-world impact. It’s only when a feature is released that it becomes “tangible” and can make a real difference. Some people working on digital projects turn to hobbies like woodworking, painting, or furniture repair as a way to create something physical and see immediate results. Releasing a feature or improvement in your digital product offers a similar sense of tangibility. It’s something you can interact with and share with others, providing a visible and appreciated result. Why Feature Factories are Problematic Itamar Gilad provides a clear explanation of why the feature factory model is flawed. In a traditional factory, every unit produced creates value because it can be sold for profit. Thus, more output equals more value. While I don’t fully agree with the notion that “every unit produced creates some value” given my sustainability-oriented mindset, I understand his point. clear explanation In software development, however, this doesn’t hold true. We often treat software development like a factory, but not everything we produce actually adds real value. In a feature factory, we end up with bloated, hard-to-maintain products featuring functionalities that few users find valuable. This mindset can lead to accumulating technical debt, reduced innovation, and growing user dissatisfaction. Over time, these issues compound, making it harder to maintain product quality, stifling creativity, and causing users to seek better alternatives. Ultimately, this can undermine a company’s competitive edge and long-term success. Recent trends in product management have introduced techniques like continuous product discovery and hypothesis validation, thanks to experts like Teresa Torres. Despite this, the 2023 State of Product Management Report by ProductPlan shows that feature factories remain a major challenge: 54% of roadmaps are designed around outputs, while only 44% focus on outcomes. The shift towards an outcome-oriented approach is slow and challenging. 2023 State of Product Management Report How to Move Away From the Feature Factory Mindset Understanding why we’re drawn to features is just the beginning. The real challenge is shifting our focus from outputs to outcomes. Our brains are wired to seek gratification and tangible results, making it difficult to detach from the products we work on. Even if we strive to move away from this mindset, our natural inclination to care about our work and seek immediate rewards remains. How can we use these brain biases to our advantage while shifting away from a feature-factory mindset? It all comes to making outcomes more tangible for your team and employing positive reinforcement based on outcomes. Here are the three key actions to take to shift away from a feature factory mindset. Firstly, during the planning stage, set specific, actionable goals that your team can directly influence . Rather than focusing on lagging indicators, aim for measurable product outcomes that can be impacted immediately by feature releases or improvements. Teresa Torres, in Continuous Discovery Habits, suggests setting product outcomes as goals because they reflect changes in customer behaviour that occur as soon as a feature is live. Additionally, ensure that metric tracking is readily accessible and emphasise its importance with regular team check-ins. set specific, actionable goals that your team can directly influence Secondly, while it’s important to recognise the team’s effort in delivering features, celebrate their achievement of goals even more . Managers should provide strategic feedback that encourages an outcome-focused mindset and reinforces positive behaviours. celebrate their achievement of goals even more Finally, engage more with users to understand how your work has affected their lives and share this feedback with your team, and potentially the entire company. This approach turns outcomes into tangible results through personal stories that resonate more deeply than raw data alone. engage more with users to understand how your work has affected their lives To effectively shift away from the feature factory mindset, focus on setting clear, actionable outcomes, celebrate genuine value-driven successes, and continuously seek user feedback to align your team with what truly matters. Although the transition might be challenging, it will ultimately lead to a stronger team, better products, and overall company growth. Hey, I’m Valeria! Thanks for reading my article. This is my first piece for Hackernoon, and I'd love to hear your feedback. Here, I’ll be sharing insights on product management, product design, and sustainability, so stay tuned for more. See you in the next one! 👋 Feature image source: Canva AI Image Generator. Feature image source: Canva AI Image Generator.

The Dopamine Trap of Feature Factories: Why We Celebrate Features and How to Focus on True Impact

Rethinking Data Leadership: Beyond Dashboards and Towards True Business Impact

The dark web refers to an encrypted part of the internet that allows users to hide their identity and location from outsiders. The dark web is not easily accessed by conventional search methods since the content is not indexed as it is in regular search engines like Google. To access data on dark web, users need to install private browser like Tor and/or use a VPN (Virtual private network) to add an additional layer of security and anonymity . Who created the Dark Web and why? It is not known as to who created the dark web, as the origins of many of the technologies that make it possible, such as the Tor Browser, are shrouded in mystery and anonymity and rightfully so. The dark web likely emerged from the combined effort of many individuals and organizations working independently or in collaboration. The dark web was created to provide a platform for anonymous communication and to protect the privacy of users. It allows individuals to access and share information without revealing their identity or location. The technology behind the dark web, like the Tor Browser, was initially developed to ensure secure and private communications for various legitimate purposes. But this anonymity has become a haven for illegal activities. Let’s look at some misunderstood facts about the Dark Web. #1 Dark web and Deep Web are the same thing Though it’s true that both dark web and deep web are unsearchable through regular search engines, they are actually completely two different sections of the internet. The terms dark web and deep web are used interchangeably,  so what is the difference? The Deep Web includes all online content not indexed by traditional search engines, such as private databases, academic journals, and personal email accounts. It encompasses a vast range of legitimate, everyday web activities. The Dark Web is a subset of the Deep Web, specifically designed to provide anonymity and privacy. It requires special software like Tor to access and is often associated with illegal activities but also used for secure communication and privacy protection. #2 The Dark web makes up the majority of the internet The Dark web is not as big as you think. Statistics show that the dark web consists of at most 60,000 domains whereas the open web comprises over 300 million. #3 The Dark web is a place for illegal activities While the dark web does have a reputation for hosting illegal activities, it is not exclusively used for unlawful purposes. Many individuals and organizations use the dark web for legitimate reasons, such as protecting privacy, bypassing censorship, and ensuring secure communication. Whistleblowers, journalists, and activists often use the dark web to communicate and share information without fear of retribution. Additionally, it provides a safe space for individuals living in oppressive regimes to access uncensored information and express their views freely. #4 Going to The Dark web is Illegal Accessing the dark web itself is not illegal. The dark web is simply a part of the internet that provides anonymity and privacy. It is used by many individuals for legitimate purposes, such as protecting their privacy, bypassing censorship, and ensuring secure communication. However, engaging in illegal activities on the dark web, such as buying or selling illicit goods, is against the law. It is important to differentiate between the technology that allows access to the dark web and the activities that take place on it. #5 The Dark web provides complete anonymity While the dark web offers a higher level of anonymity compared to the surface web, it does not provide complete anonymity. Users can still be traced through various means, such as law enforcement tracking techniques, vulnerabilities in software, or operational security mistakes made by users themselves. It's essential to understand that no system can guarantee absolute privacy or anonymity. #6 Tor is the only dark web source Tor is the most well-known tool for accessing the dark web, but it is not the only one. Other networks and tools, such as I2P (Invisible Internet Project) and Freenet, also provide access to dark web content. Each of these tools has its own methods for ensuring privacy and anonymity, and they may be used for different purposes. Tor is popular due to its ease of use and widespread adoption, but it is just one of several ways to navigate the dark web. The dark web refers to an encrypted part of the internet that allows users to hide their identity and location from outsiders. The dark web is not easily accessed by conventional search methods since the content is not indexed as it is in regular search engines like Google. To access data on dark web, users need to install private browser like Tor and/or use a VPN (Virtual private network) to add an additional layer of security and anonymity . Who created the Dark Web and why? It is not known as to who created the dark web, as the origins of many of the technologies that make it possible, such as the Tor Browser, are shrouded in mystery and anonymity and rightfully so. The dark web likely emerged from the combined effort of many individuals and organizations working independently or in collaboration. The dark web was created to provide a platform for anonymous communication and to protect the privacy of users. It allows individuals to access and share information without revealing their identity or location. The technology behind the dark web, like the Tor Browser, was initially developed to ensure secure and private communications for various legitimate purposes. But this anonymity has become a haven for illegal activities. Let’s look at some misunderstood facts about the Dark Web. #1 Dark web and Deep Web are the same thing Though it’s true that both dark web and deep web are unsearchable through regular search engines, they are actually completely two different sections of the internet. The terms dark web and deep web are used interchangeably,  so what is the difference? The Deep Web includes all online content not indexed by traditional search engines, such as private databases, academic journals, and personal email accounts. It encompasses a vast range of legitimate, everyday web activities. Deep Web The Dark Web is a subset of the Deep Web, specifically designed to provide anonymity and privacy. It requires special software like Tor to access and is often associated with illegal activities but also used for secure communication and privacy protection. Dark Web #2 The Dark web makes up the majority of the internet The Dark web is not as big as you think. Statistics show that the dark web consists of at most 60,000 domains whereas the open web comprises over 300 million. #3 The Dark web is a place for illegal activities While the dark web does have a reputation for hosting illegal activities, it is not exclusively used for unlawful purposes. Many individuals and organizations use the dark web for legitimate reasons, such as protecting privacy, bypassing censorship, and ensuring secure communication. Whistleblowers, journalists, and activists often use the dark web to communicate and share information without fear of retribution. Additionally, it provides a safe space for individuals living in oppressive regimes to access uncensored information and express their views freely. #4 Going to The Dark web is Illegal Accessing the dark web itself is not illegal. The dark web is simply a part of the internet that provides anonymity and privacy. It is used by many individuals for legitimate purposes, such as protecting their privacy, bypassing censorship, and ensuring secure communication. However, engaging in illegal activities on the dark web, such as buying or selling illicit goods, is against the law. It is important to differentiate between the technology that allows access to the dark web and the activities that take place on it. #5 The Dark web provides complete anonymity While the dark web offers a higher level of anonymity compared to the surface web, it does not provide complete anonymity. Users can still be traced through various means, such as law enforcement tracking techniques, vulnerabilities in software, or operational security mistakes made by users themselves. It's essential to understand that no system can guarantee absolute privacy or anonymity. #6 Tor is the only dark web source Tor is the most well-known tool for accessing the dark web, but it is not the only one. Other networks and tools, such as I2P (Invisible Internet Project) and Freenet, also provide access to dark web content. Each of these tools has its own methods for ensuring privacy and anonymity, and they may be used for different purposes. Tor is popular due to its ease of use and widespread adoption, but it is just one of several ways to navigate the dark web.

Are The Most Common Conceptions Of the Dark Web True?

There is an out from McKinsey on the impending impact of AI on an enterprise’s cloud investments. interesting report There was a quote early on in the piece where McKinsey states: “While the possible impact varies by sector, adopting cloud represents an opportunity for the average company to increase profitability by 20 to 30 percent.” To many, this would be a clarion call to put everything in the public cloud - but there is significant nuance added in the next sentence: “Many digital-native companies are already taking full advantage of this opportunity. Nearly one-third of the EBITDA value gain over the past decade in the S&P 500 has come from just eight digital-native companies ” that utilized cloud-like infrastructure. Cloud-like infrastructure. Not “because they used a public cloud”, but because they adopted the The report is excellent and we recommend it highly. cloud operating model. There is another truth out there that we see time and time again and that is, by repatriating workloads from the cloud, companies save on average 60%. This is what we see consistently from the teams that have published their numbers like , , , and . It is what the one of the biggest enterprise security companies (and our customer) saved (but didn't publish). 37Signals X.com Prerender Ahrefs So the question becomes - how do you increase profitability by both going to the cloud AND from leaving it. The answer is in the adoption of the cloud operating model. Adopting the cloud operating model changes the way you think about infrastructure, the developer experience and end to end technical efficiency (from the data team to IT).  Training, tuning and deploying generative AI models requires proximity to real-time business processes and data.  The McKinsey report also predicts that over the next decade close to half the data will continue to be generated on premise.  Depending on a number of factors like data privacy, point-of-sale systems and others an organization should consider their on-premise vs public cloud data architecture carefully. The cloud operating model delivers infrastructure as code. That means smart software and dumb hardware. Google (TPU), AWS (Graviton) and Azure (FPGA) all have their own silicon, but these are designed for general purpose workloads. Software is what makes them sing. That is the model going forward. Inexpensive yet powerful commodity hardware that is frankly disposable and reusable. That is why you don’t find appliances in the public cloud or in the cloud operating model. The cloud operating model means sharing and reusing preconfigured tooling and application patterns across developer disciplines. This approach includes a unified consumption layer with self-service for developers and a standardized tech stack to support speed, agility, and security. The cloud operating model also enhances technical  efficiency through managed services (databases, key value stores, security). It requires automation and standardization of IT processes, such as deployment, scaling, and management. It facilitates CI/CD practices, enabling frequent and automated code deployments. Each of these (and others) makes a more efficient organization. The net of it is that two things can be true at the same time. You can “go to the cloud” and become more profitable AND you can “repatriate” and be more profitable. The common denominator is the model. If you want to talk about what workloads belong where - hit us up on and we can share our thinking. You will find us remarkably honest in our advice. If you belong on the public cloud - we have no problem saying that, because if you are successful, at some point you will want to come back out. It is all about what you optimize for. hello@min.io Also appears . here

Quantum State: How Two Things Can Be True at the Same Time

কোয়ান্টাম স্টেট: একই সময়ে দুটি জিনিস কীভাবে সত্য হতে পারে

Quantenzustand: Wie zwei Dinge gleichzeitig wahr sein können

Estado cuántico: cómo dos cosas pueden ser ciertas al mismo tiempo

État quantique : comment deux choses peuvent être vraies en même temps

क्वांटम स्थिति: एक ही समय में दो चीजें कैसे सच हो सकती हैं

量子状態: 2 つのことが同時に真実になる仕組み

양자 상태: 두 가지가 동시에 참일 수 있는 방법

Estado quântico: como duas coisas podem ser verdadeiras ao mesmo tempo

Квантовое состояние: как две вещи могут быть правдой одновременно

Kuantum Durumu: İki Şey Aynı Anda Nasıl Doğru Olabilir?

Trạng thái lượng tử: Làm thế nào hai điều có thể đúng cùng một lúc

量子态：两件事如何同时成立

The Noonification: Why Open Source Language Models Are True “Open AI” (2/5/2024)

In 2015, a called OpenAI was formed to create “broadly and evenly distributed” AI. Fast forward to 2024, and OpenAI has transitioned into full-on for-profit mode, hoarding access to LLMs behind a transactional API service. Most recently, they’re seeking a . nonprofit $100 billion valuation The past decade of AI progress has been dominated by large tech companies like Google, Meta, and OpenAI releasing ever-larger proprietary language models. From Bard and Claude to GPT-4, much of the state-of-the-art in natural language processing (NLP) has remained concentrated in the hands of a few research labs. However, the long-term future of AI lies not in more private bigger models served exclusively through APIs but rather with open-source language models built in the open alongside communities. Open-Source Language Models In recent years, a handful of startups, universities, and dedicated individuals have helped pioneer this open model of language model development. The latest model continuing this open-source lineage is . Weighing in at 1.8 billion parameters, Danube demonstrates surprising capability even compared to other publicly available models many times its size. The team meticulously designed, trained, and validated Danube completely transparently, with the full report available on . H2O-Danube-1.8B H2O.ai arXiv Rather than hoarding access, released Danube's full parameters and training code openly on HuggingFace. Within days of the initial announcement, curious developers began freely experimenting with the model, showcasing rapid innovation generation simply not feasible with proprietary models. As of writing, the entire h2o-danube-1.8b-chat model has been download over 500 times on HuggingFace. H2O.ai Anyone can use the model with the library, following the below code, courtesy of h2o’s HuggingFace repo: transformers import torch
from transformers import pipeline

pipe = pipeline(
    "text-generation",
    model="h2oai/h2o-danube-1.8b-chat",
    torch_dtype=torch.bfloat16,
    device_map="auto",
)

# We use the HF Tokenizer chat template to format each message
# https://huggingface.co/docs/transformers/main/en/chat_templating
messages = [
    {"role": "user", "content": "Why is drinking water so healthy?"},
]
prompt = pipe.tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)
res = pipe(
    prompt,
    max_new_tokens=256,
)
print(res[0]["generated_text"])
# <|prompt|>Why is drinking water so healthy?</s><|answer|> Drinking water is healthy for several reasons: [...] H2O believes collaborating openly remains the ultimate key towards democratizing access to AI and unlocking benefits for the many rather than wealth for the few. Other Open-Source Language Models The open-source AI ecosystem continues expanding with developers globally collaborating on shared models. Beyond H2O-Danube-1.8B, numerous noteworthy initiatives aim to prevent concentration of knowledge within walled gardens. MPT Developed by startup MosaicML, the incorporates techniques like mixture-of-experts parallelization and context length extrapolation to improve efficiency. Machine Programming Transformer (MPT) Falcon Falcon’s biggest open-source LLM is a whopping beast, outperforming the likes of , , , and 180-billion parameter LLaMA-2 StableLM RedPajama . MPT At that size, it’s recommended to have 400 gigabytes of available memory to run the model. Mistral Founded by ex-Googlers and Meta researchers, Mistral released the 7 billion parameter in September 2022. Mistral 7B achieves competitive performance among open models nearly matching the closed GPT-3 in sample quality. Mistral 7B model Legacy Models Beyond newly launched models, earlier open-source models continue to empower developers. GPT2 from OpenAI and GPT-J from EleutherAI both hold historical significance despite lagging behind modern architectures. And Transformers like BERT gave rise to an entire subclass of NLP breakthroughs powering products globally. The democratization narrative only strengthens thanks to passionate communities generously contributing their creations back to common pools of knowledge. A More Equitable Future In many ways, proprietary language models risk recreating many inequities the tech industry continues wrestling with. Concentrating knowledge within wealthy organizations excludes smaller teams from shaping progress early on. And later makes integration prohibitively expensive once available purely through transactional APIs. Open-source models are vital to seeding a more equitable way forward. One where agency lies closer to diverse communities actually building concrete AI applications. The long arc of progress only Bends towards justice when people come together united behind the technology itself rather than any one organization seeking to control it. Danube and the open paradigm it represents offers but one glimpse into an alternate vision. One driven not by short-term profits or prestige but by empowering developers everywhere to freely build upon each other's shoulders. There will always remain space for proprietary work, but the true future of AI lies open. Community-Driven Innovation Releasing open-source models draws contributions from a motivated community of developers and researchers. This collaborative style of working in the open unlocks unique opportunities. Experts across organizations can peer review each other's work to validate techniques. Researchers can readily replicate and extend new ideas instead of reinventing the wheel. And software engineers can rapidly integrate and deploy innovations into customer offerings. Perhaps most promisingly, the open paradigm allows niche communities to gather around customizing models for specific use cases. Teams can sculpt versions tailored to particular topics like medicine, law, or finance which outperform generic models. These specialized models then get shared back to benefit the rest of the community. Together, groups make collective progress not possible within any single closed lab.

Why Open Source Language Models Are True “Open AI”

কেন ওপেন সোর্স ল্যাঙ্গুয়েজ মডেলগুলি সত্য "ওপেন এআই"

Warum Open-Source-Sprachmodelle echte „Open AI“ sind

Por qué los modelos de lenguaje de código abierto son una verdadera "IA abierta"

Pourquoi les modèles de langage Open Source sont de véritables « IA ouvertes »

क्यों ओपन सोर्स लैंग्वेज मॉडल सच्चे "ओपन एआई" हैं

オープンソース言語モデルが真の「オープン AI」である理由

오픈 소스 언어 모델이 진정한 "Open AI"인 이유

Por que os modelos de linguagem de código aberto são verdadeiras “IA aberta”

Почему языковые модели с открытым исходным кодом являются истиной «Открытый ИИ»

Açık Kaynak Dil Modelleri Neden Doğrudur?

Tại sao các mô hình ngôn ngữ nguồn mở lại là “AI mở” đích thực

为什么开源语言模型是真正的“开放人工智能”

What is The True Price of Generative AI?

জেনারেটিভ এআই এর আসল দাম কত?

Was ist der wahre Preis der generativen KI?

¿Cuál es el verdadero precio de la IA generativa?

Quel est le vrai prix de l’IA générative ?

जेनरेटिव एआई की सही कीमत क्या है?

Stories, News & Mentions about TRUE

True’s Stories on HackerNoon