Agile can be a powerful tool, but it has grown into such a complicated industry that people often lose sight of the underlying principles that drive it. This leads businesses to fail to unlock its full potential and puts them at a disadvantage to their more agile competition.

I've been involved in software and technology development — off and on — for the better part of 25 years, as both an engineer and a product manager. Over the course of my career, I’ve experienced all manner of paradigm and process for developing products, including waterfall, agile, and all manner of amalgamations in-between. One thing I’ve consistently noticed is a trend of smart, capable, accomplished leaders and practitioners who claim to be doing agile, but in failing to understand what agile truly is — and isn’t — , consistently fail to reap its full benefits.

What Agile Is Not

• A set of rigid processes. Process is at best an uneasy ally of agile, a necessary evil to allow an agile mindset to function in a complex operating business. Some agile processes skew more pure, some skew towards borrowing agile concepts. But no matter what process you implement, no matter how pure or blessed by certifications or trendy, the mere act of implementing an agile process will not make you agile. Agile is a mindset, not a costume. Process is form, agile is function.
• A magic talisman. Attaching the word “agile” to PowerPoint slides, processes, and certification programs won’t magically unlock the benefits of agile. Let’s face it: Agile is trendy. Everyone wants to be agile. Every executive thinks it will unlock hidden value in their company. Boards want to know that the company is doing “agile.” Be skeptical of anything that tries to use agile as a brand and instead focus on the underlying principles.
• A magic bullet. Agile is a powerful tool, if you are a product-focused company with small, self-directed teams that must innovate in the face of uncertainty. If that doesn’t describe your company, YMMV. Agile is a powerful tool, not the only tool, and it’s not always the best tool for every company in every situation. But if your company does match this description, agile can be the unfair advantage that lets you compete above your weight class.
• A lack of strategy and planning. Agile does not mean that we operate with chaos, that we don’t have clear objectives we are trying to accomplish, or that we blindly say “yes” to every customer request or every opportunity for revenue. It is also doesn’t mistake the freedom to change plans with not having any plan at all. Agile is about learning continuously and validating assumptions so that we can quickly and cheaply make adjustments to stay on course, not about operating without any destination in mind.
• Only for delivery. Waterfall product planning coupled with agile delivery (or more often, just using “sprints” to deliver) unlocks at most 1/2 the value of agile. If you’re not also doing agile product discovery, and if your company isn’t operating with an agile mindset, you’re leaving a whole heap of value on the table.
• Perfect. Agile is about giving up one set of valuable things for another set of valuable things, in the belief that doing so is the right strategic trade-off to build better products, gain a competitive advantage, and deliver superior outcomes. It will be uncomfortable at first, and you will have to give up a few things that you rightly place value on in order to gain these advantages. Don’t fall into traps that promise to deliver the benefits without any sacrifice; there is no such thing.

Agile Starts With a Manifesto

Agile didn’t come from nowhere. It was a response to existing software development practices, and started with a manifesto in 2001:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Take a moment to pause and reflect, especially on that last line. It recognizes that there is often a tension between the things that tend to produce desired outcomes on the left, and more traditional artifacts that help to operate a business on the right. The agile manifesto is ultimately about placing greater value on outcomes than operations, about giving up emotional comfort and some measure of predictability in an effort to deliver outsized value.

It’s important to consider that agile didn’t emerge from a vacuum; it emerged in response the shortcomings and disappointments of traditional software development, now often referred to as “waterfall.” In waterfall development, we typically have long development cycles where we:

1. Gather requirements and/or sign contracts with customers.
2. Spend significant time and resources planning products and features to fulfill the requirements and contracts.
3. Spend significant time developing and testing the next major release, which includes all the new features and updates we’ve planned.
4. Plan and launch our release.
5. Measure outcomes (finally!) which often fail to live up to our expectations.

The fundamental flaw in this approach is the amount of time it takes, versus how rapidly things change or how frequently we learn. In waterfall, if we learn something along the way that impacts a previous step, we have to wait until after the release is launched to do anything about it. And even if we manage to learn everything possible at each step before moving on, it is often the case that the customer needs, or market conditions, have changed by the time we finally release.

Agile then is nothing more than an acknowledgment that learning needs to be constant, opportunities to course-correct need to be frequent, and we must move at least as fast as the world around us to succeed, even if that means de-prioritizing things that might otherwise be valuable to operating a business.

Of course, the original agile manifesto was written by and for software developers. Since then disciplines like product management and principles like Lean have widened the scope of what it means to be agile. However, it’s worth revisiting the original principles around agile development:

12 Principles Behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Unlocking the Full Power of Agile

Agile works best when the whole company adopts an agile (and Lean) mindset. This is especially true for the disciplines that make up product teams and stakeholders — product managers, product owners, product designers, product marketers, project managers/scrum masters, tech leads, developers, and testing/QA, as well as customer success, marketing, and sales.

How to Avoid 10 Common Mistakes I’ve Seen

Mistake #1: Creating objectives based on outputs.

Instead: Have clear, measurable objectives in the form of desired outcomes.

These should not change frequently, and will be the goalposts that your product teams will continually work towards. Focus on outcomes, not output, and make sure these outcomes are true drivers of business success.

Mistake #2: Focusing too heavily on process and frameworks.

Instead: Start with a process that seems reasonable and evolve it over time.

None of them are perfect. Choosing one over the other will not make or break your products. Pick one you think will work for you, perhaps biasing towards a simple and straight-forward approach, and don’t overcomplicate the decision — you can always evolve your process (being agile about agile).

And keep in mind who you are: A team of 3 testing a business idea probably needs nothing more than Lean, while a massive corporation with 10s of 1000s of employees and no history with agile might opt for a more “agile-like” compromise like SAFe. Most teams should probably just focus on combining agile product discovery (see: Marty Cagan, Steve Blank) with something like Kanban or Scrum for agile product delivery.

Mistake #3: Handing customer requirements to your product teams.

Instead: Let your product teams talk to customers directly.

Good product teams know how to talk to customers and unlock deep understanding of their work, problems, and opportunities. This is one of the most powerful things your teams can do to gain insights that lead to great products. Customers know their problems better than anyone, but rarely do they even know what solutions are possible. Give your product teams an opportunity to delight and amaze your customers.

Product teams should be talking to sales, customer success, and marketing often, but don’t hide your customers away from your product team; non-product people are rarely trained in how to get the information that product teams need. Plus you miss the opportunity to let product teams co-create with your most enthusiastic customers.

Mistake #4: Micromanaging your products and product teams.

Instead: Give product teams autonomy.

Allow them to be missionaries, not mercenaries. Let them focus ruthlessly and methodically on delivering value to customers and outcomes to the business. Organize around products, not projects. Measure teams on business results, not schedules and plans. Do not make promises on behalf of teams without their consent. Focus teams on objectives and hold them to agreed upon outcomes, but empower them to make their own decisions on how best to achieve those outcomes. They’ll surprise you with what they come up with.

Mistake #5: Working in silos organized by function.

Instead: Make sure product teams are cross-functional and long-lived.

A good product team at a minimum includes product managers and designers, tech leads, and developers. They should form a long-term team that works closely together, but that does not report to each other. Avoid silos and throwing things over the wall. Make sure your product teams have shared knowledge by learning together. Make sure members of your teams have shared responsibility for outcomes, and that all members of a product team can communicate frequently and easily with stakeholders.

Mistake #6: Focusing on knowing the right answer.

Instead: Focus on learning and (in)validation.

Product ideas are hypotheses, and most are not going to work, no matter how smart the person who came up with them or how educated their opinion. This is true even for visionary product leaders and CEOs. Be humble. Focus on cheaply and quickly learning and sorting the good ideas from the bad using empirical means. Validated learning, done quickly and cheaply, even when a hypothesis is proven wrong, is just as valuable as lucking into the right answer on the first try, and you’ll exponentially reduce the cost of your bad ideas.

Mistake #7: Waiting until release to measure (or not measuring at all).

Instead: Measure early and often.

Do not wait until something is released to measure its outcome. Agile delivery is only half the battle. By the time we commit to building something to production quality, we should already have a good idea of the likely outcome and be confident in our solution. We achieve this by pairing agile product discovery with agile product delivery.

Mistake #8: Focusing on adherence to roadmaps and project plans.

Instead: Build-in frequent opportunities to course-correct.

Learning is pointless if we don’t take appropriate action in response. Roadmaps, project plans, and customer promises, while valuable for operating a business, often cause teams to be afraid to veer “off-course.” No matter how experienced the team, and how much management promises to “keep things agile,” there is a very real tendency to subconsciously supplant our outcome-based goalposts with output-based ones from our roadmaps and project plans. Avoid these tools if you can, or if you cannot, take proactive and frequent steps to minimize the chance of losing the forest for the trees.

Mistake #9: Delivering big releases with lots of changes.

Instead: Deliver in small, frequent releases.

100% of customers would rather have usable and valuable software today than tomorrow, and learning and validation don’t end once we release. Not to mention that lots of small, frequent changes are less disruptive to users than a large changes all at once. Be ruthless in breaking up delivery into minimum viable increments that deliver user value, and obsessively measure outcomes to incorporate feedback and learning back into the product discovery process.

Mistake #10: Believing that agile doesn’t require sacrifice.

Instead: Prepare for discomfort and consider carefully.

In order to unlock the value of agile, you’re going to have to make some sacrifices. Prepare yourself for that. You might be able to unlock some value by adopting bits and pieces, but ultimately your competitors who fully embrace agile will have an unfair advantage. If you’re on the fence, experiment with a single team and let them fully embrace agile without being forced to fit it into existing processes. You might be surprised by the results.

When we started Figaro, we set out to build technology that would power fairer financial markets, free from colocation, high frequency trading, and dark pools. We wanted to build a system where anyone could compete on a level playing field based on skill and market knowledge, rather than insurmountable technical and financial barriers designed to ensure that the same privileged few always win.

Early on we realized the key to this was building distributed exchanges, with each member node independently owned and operated, and with full data transparency and cryptographic proof of best execution order matching. Only then could we create markets insulated against the financial influence of a few major players.

To accomplish our goals, we’ve embraced blockchain as a core technology. This game-changing technology enables secure distributed and decentralized networks in a way that has never before been possible. Unfortunately, no off-the-shelf blockchain technology allows for operating limit order books and matching engines at scale while maintaining full cryptographic proof of order book state and best execution order matching. That means we’ve had to build our own. FigaroDB is the result of almost 2 years of heavy R&D, and we are excited to share our results.

Background

The naive solution would have been to create limit order books and matching engines using smart contracts and the Ethereum Virtual Machine (EVM). Unfortunately, the performance characteristics of the EVM and the relatively intense data requirements of keeping a sorted order book prove to be unworkable, even with a dedicated network to avoid excessive “gas” costs. This reflects the experience of the DEX community at large, which abandoned smart contract exchanges in favor of relay networks. However, relay networks use centralized order books and matching engines, with only settlement being decentralized. This means they are highly vulnerable to colocation, front running, and dark pools. To create fairer financial markets, we require a solution that is fully decentralized.

FigaroDB

With FigaroDB, we’ve been developing a cryptographic database designed specifically for order books and matching engines. As a design goal, we require real world scalability, the ability to generate merkle roots of order book state to support distributed computing, and the ability to provide compact merkle proofs of best execution order matching in order to provide full decentralization without loss of security. After iterating several approaches and versions, we’ve been able to alpha test a prototype that meets those design goals, and we share our benchmark results below.

Benchmarks

PC with 1TB NVMe SSD PCIx4, Quad Core i7, 32 GB RAM

Test 1: Seed 500 Ask orders, benchmark matching Bid orders throughput

Result: 16500 tx/s

Test 2: Seed 50k Ask orders and 50k unmatched Bid orders, benchmark matching Bid orders throughput

Result: 12500 tx/s

Test 3: Seed 50k Ask orders and 50k unmatched Bid orders, benchmark time to create complete Ladder from disk

Result: 100ms

These are exciting results, because this means FigaroDB can operate as part of a decentralized exchange supporting over a billion transactions per day, independent of order volume, even before sharding. This is key to ensuring that Figaro can operate at the scale of global financial markets and serve as an alternative to traditional centralized financial exchanges.

What’s Next?

With FigaroDB, we finally have a means of operating fully decentralized exchanges at scale. Keep an eye on Figaro as we continue to develop a custom blockchain to create the world’s fairest financial markets. We intend to release Figaro Core, including FigaroDB, as source-available software under both noncommercial and commercial licenses. For more information or opportunities to partner with Figaro, you can reach us at info@figaro.tech.

Announcing FigaroDB was originally published in Figaro on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve noticed a lot of discussion lately around what exactly makes something like Coinbase a centralized exchange and what exactly the decentralized vs. centralized debate is all about. A common misconception is that it’s only about whether or not an exchange keeps custody of your crypto, but that’s a very narrow definition and there’s actually a far more disruptive and subversive movement happening around decentralized exchanges (DEX). Admittedly, it doesn’t help matters that terms in the cryptocurrency space can often be jargon-y, confusing, and sometimes mean more than one thing depending on the context. So herein lies my attempt to provide some (simplified) clarity and make the case for a bigger DEX picture.

Centralized vs. Decentralized = Who Has The Power?

In the cryptocurrency/blockchain space, when we talk about centralization vs. decentralization, we are usually talking about who has authority and power on a network. Oftentimes we are talking about hashing power or consensus authority e.g., Bitcoin centralization and security if a few mining pools collectively control more than 51% of the hashing power.

This is because the more decentralized a blockchain network, the harder it is to achieve 51% control through collusion or conspiracy, and therefore, the more secure and trustworthy the network. In the case of exchanges, we are also talking about who controls the market data feed and the matching engine, because whoever controls those things controls the ability to grant special access and make or break fortunes.

But before we talk about decentralized vs. centralized exchanges, including how they work and the trade-offs between them, it helps to understand why custody of cryptocurrencies is not the whole story behind (de)centralization.

Wallets != Centralization/Decentralization

A common definition is that centralized exchanges are ones that take custody of cryptocurrencies on behalf of users and decentralized exchanges are ones where users manage their own cryptocurrencies — but that’s really very narrow and centers around online vs. offline “wallets.” It’s important to note that the wallet debate isn’t about power and authority, but rather about ease of use vs. security. To better illustrate, it helps to understand a couple of things about crypto wallets.

The first is that nobody holds your crypto — not you, not centralized exchanges, not banks or other institutions. Or more accurately, everybody holds your cryptocurrencies, because they only exist as entries in distributed ledgers, a copy of which is maintained by every node on a network.

The second is that the ability to spend or transfer your crypto is dependent on one thing and one thing only: possession of the secret key that “unlocks” it. A wallet is simply a device that securely holds the secret key to your account — i.e., it doesn’t hold your cryptocurrencies, it holds the secret keys to spending your cryptocurrencies. Whether you hold onto your secret keys or entrust them to a 3rd party is a matter of convenience and security.

Wallets come in two main flavors:

• Online (sometimes called “hot”): operated by a 3rd party, e.g. Coinbase, where your secret key is kept on a 3rd party server and accessed with a username and password; very easy to use, but if the 3rd party doesn’t practice good security, your secret key might be stolen
• Offline (sometimes called “cold”): your own software/hardware/piece of paper/brain that holds your secret key; harder to use, and if you don’t practice good security, your secret key might be stolen

There’s a very lively debate about whether the convenience of online wallets is worth trusting a 3rd party with your finances, but like most online financial accounts, it comes down to the security measures (and insurance policies) of the online wallet you use, and there is a very strong argument that long-term mainstream adoption will only occur through online wallets. There’s also a strong argument that people tend to overestimate their ability to practice good security, and that offline wallets might not be all that more secure in practice. But while this debate is important, there’s a much more important debate going on around centralized and decentralized exchanges.

Centralized/Decentralized Exchanges — Who Controls What

As mentioned previously, the central question of the decentralization debate, at least in regards to exchanges — whether crypto, stocks, futures, or any other asset class — is (or at least, in my opinion, should be) whether the order book, data feed, and matching engine are centrally located and/or centrally controlled, or whether they are decentralized, often by running, in whole or in part, on a public blockchain — that is the exchange itself runs on a blockchain, rather than just transacting in blockchain-based assets.

Centralized exchanges have a couple of technological upsides — they tend to have very fast transaction times and very fast data feeds. Think high-frequency trading. They also tend to be physically located in a single data center and controlled by a single authority — this means that an advantage can be gained by simply locating as close as possible, and most centralized exchanges will sell you physical proximity (for a hefty sum). This also means that one entity creates and controls the rules of the system and we must rely on regulation (often self-regulation) to ensure fair play. What makes something like Coinbase different than the NYSE really comes down to asset types, and technologically they are more alike than different.

Decentralized exchanges (DEX) are the opposite — order books, data feeds, and matching engines are maintained in a decentralized fashion without a single physical location or source of origin, with the rules enshrined in publicly auditable software and executed by the network. It’s still very early in the development of DEXs and there are many variations in existence (and even more in development) achieving varying levels of decentralization, but a consistent theme is that DEXs provide a more level playing field with more democratic access to data, order matching, and rule creation. Depending on the details of how a DEX operates, its also possible that there may be less need for regulation, or that a system will lack any central entity that could be regulated, and security and fairness will come in the form of audited source code. And depending on your view of high-frequency trading, the tradeoffs in terms of slightly slower markets might not be a tradeoff at all.

If you’re curious as to how a DEX operates, we can loosely categorize them into one of three flavors:

• Direct P2P: operate purely peer-to-peer with only a simple order book and no matching engine, with parties making direct transactions with each other (sort of like the digital equivalent of an open-outcry trading pit); recent trends tend to focus on helping buyers and sellers find each other and/or maintaining privacy and anonymity
• Offline Order Matching: maintains a record of all transactions, including open and matched orders, on a blockchain, but the matching engine runs off-blockchain with varying levels of (de)centralization; recent trends usually focus on trying to bring some of the benefits of decentralization to this more centralized model of order matching
• 100% Blockchain: everything, including the matching engine, occurs on the blockchain in a decentralized fashion, which is the holy grail of DEX; recent trends focus on solving the technical challenges of running everything on a blockchain, thus far with limited success (most blockchains really aren’t designed to operate financial exchanges)

Note that there’s no technological reason that DEXs can’t provide an online wallet as an ancillary service — its just a service that holds your secret keys — and as projects mature we should expect that online wallet services for DEX exchanges will start popping up to provide better user experiences.

Wrap-Up

Ease of use/rate of adoption vs. security/custody is an important debate, but when we talk about DEXs in terms of decentralized control and operation of data and matching engines, we are talking about something that has the potential to be truly disruptive — a reimagining of what an exchange is and who owns and controls them, with the power to truly democratize financial markets. That’s a lot bigger than who has custody of your cryptocurrencies.

Disclosures

I own small amounts of BTC and ETH, and I am part of a team that has been working for the last year (in stealth mode) on an open-source blockchain for DEX financial markets.

Decentralized Exchanges was originally published in Figaro on Medium, where people are continuing the conversation by highlighting and responding to this story.

A confession: I’m not a cryptocurrency trader. You’re far more likely to find me hacking on low-level blockchain protocols than staring at cryptocurrency charts trying to predict price movements.

I’m not really a trader at all — I’ve always been more of a long-term investor with an eye towards assessing whether I think an asset is under or over-valued given fundamental analysis and prospects for future growth. In between computer science technical references and cyberpunk novels, you’ll find Graham, Malkiel, and Boggle on my bookshelves. So if you’re looking for guidance on the next hot alt-coin or where the price of BTC is headed in the short-term, take what I have to say with a grain of salt.

But if you’d like to better understand the fundamental differences between various categories of cryptocurrencies and — more importantly — a way to evaluate their underlying value and long-term potential, maybe I can help.

So without further ado, a categorization and analysis of various cryptocurrency types and how to evaluate their long-term value, kept short enough to read over your morning coffee (or evening cocktail).

Store Of Value Networks — Ex: BTC, LTC, ZEC, XMR, DOGE. These are all cryptocurrencies that focus on transacting themselves; e.g., the main functionality of Bitcoin is to record and transfer BTC. Most are native cryptocurrencies to a blockchain (native = part of the underlying protocol), or in the case of DogeCoin (originally created as a joke), operating as a smart contract hosted on a parent blockchain — in this case, Ethereum.

Some are focused on transparency, some on privacy, but all have in common (1) a fluctuating market value, and (2) little economic utility beyond their ability to hold value over time (think digital equivalent to gold).

This is the category most well-suited to technical analysis, as they are only valuable so long as a sufficient number of people say they are valuable, and they have little fundamental value beyond their market demand.

Payment Networks — Ex: BTC, LTC, ZEC, USDT, XRP. Notice the overlap with the previous category. That is because most cryptocurrencies that have become stores of value started with the intention of being payment networks — e.g., Bitcoin’s initial vision was being a digital currency that offered a solution to the double-spend problem, not as a crypto asset that would skyrocket in market price and transfer wealth.

Many of the communities surrounding these coins still see them as payment networks, but wildly fluctuating values of any currency leads to poor suitability as money. And while stablecoins (cryptocurrencies fixed to a fiat currency via fluctuating supply) offer an interesting solution by holding values steady, you can’t really invest in them (except perhaps as some sort of forex play) since their value will never increase or decrease.

However, for payment protocols that offer a cryptocurrency with a fluctuating price, we can evaluate potential value based on the convenience, usability, and partnerships/acceptance of the payment network — the same as we might evaluate any other payment technology — coupled with an assessment of the role that the crypto asset plays in the system and whether or not its demand should be directly impacted by the volume of payment transactions.

Compute Networks — Ex: ETH, EOS, QTUM. This is where things get interesting, because these aren’t cryptocurrencies in the same sense as the previous two categories. Instead they are blockchain compute networks capable of running scripts (smart contracts) that form the backend for client applications (dApps). Think AWS but running P2P instead of in a centralized data center. Here the native cryptocurrency serves simply to determine how you allocate scarce computing resources, e.g., if you want to access a smart contract/dApp on Ethereum, even a transaction involving another hosted token, you have to pay your transaction fees in ETH. That is to say, if you want to use Ethereum dApps, you must purchase ETH, creating demand against a (largely) fixed supply.

That also means that we can evaluate the value of each compute network primarily based on: (1) the number (or future number) of smart contracts/dApps hosted on each blockchain network, along with the transaction volume each generates (or is likely to generate); (2) the total transaction volume that the network is capable of processing; and (3) the attractiveness of the platform to dApp developers along with the costs of switching networks. In other words, assuming a cryptocurrency is used to pay transaction fees, we can evaluate its value much in the same way we might evaluate any other infrastructure or platform technology.

Utility Networks — Ex: PowerLedger, Waves, Filecoin, XYO. These are similar to compute networks, but usually have a more narrow focus/optimizations and are often hybrid networks that connect blockchain technology to some external resource/technology/asset, or occasionally bridge between various blockchains. These may be implemented as special-purpose blockchains, but also may be hosted on compute network blockchains in the form of smart contract protocols.

We can evaluate these cryptocurrencies in a similar fashion to compute networks, with a few additional considerations: (1) how central a native cryptocurrency and/or token is to the utility of the network/protocol; (2) how much demand there is (or will be) for the given utility/protocol; (3) how much of a benefit decentralization provides to the utility/protocol; and (4) how much of a benefit a special-purpose blockchain provides over a more general compute network blockchain, or how much of a benefit a protocol token provides over a smart contract making use of the native cryptocurrency of the host blockchain.

Voting/Security/Misc Tokens—Ex: DOA, CryptoKitties, EOS ICO on Ethereum. Almost always implemented as smart contracts on a general compute network blockchain, the gist of these tokens is that they provide a form of decentralized crowdfunding for a given project. They may represent voting rights, or shares of profits, or nothing at all other than the goodwill of project funders. They might represent reward networks, prepaid purchases, or in-game items. Where these tokens represent a distributed ledger for an otherwise traditional investment asset class (revenue share, equity, debt), the token value can largely be evaluated based on the underlying asset it represents. Where they represent items that would not traditionally be considered an investment, the argument for any investment value in the tokenized version is hard to justify.

Conclusion

The important takeaway is that you can’t use the same set of metrics to evaluate the potential future values of BTC, ETH, XRC, XYO, and the latest random ICO, any more than you can evaluate stocks, bonds, and gold using the same set of metrics. The factors that influence demand, not to mention differences in how supply is controlled, are simply too different. Looking at the problem purely in terms of current mindshare or market cap ignores those fundamental differences — and the rather nascent state of cryptocurrency markets and analysis — at the risk of making long-term investment mistakes.

Disclosures

I own small amounts of BTC and ETH, and I am part of a team that has been working (in stealth mode) on an open-source utility blockchain in the financial markets space for the last year.

One way we do this is by extracting meaningful keyword phrases from reviews (future blog post). Our model for extracting keywords gives us meaningful (to humans) phrases, but doesn’t classify keywords into topics or topic probabilities.

Our keyword phrases end up looking something like:

“juicy burger”, “rude waitress”, “service was terrible”, …

We’d like to be able to automatically assign these keywords to topics, so that you get something like:

“Food”: [“juicy burger”],
“Service” : [“rude waitress”, “service was terrible”],
…

To make things extra interesting, we’d also like users to define their own topics on the fly, since they know their businesses better than we do.

At the end, we’re going to be able to do this:

for k, i in zip(keywords, topic_idx):
  print(‘“%s” is about %s’ %(k, topic_labels[i]))

Output:

“pizza was gross” is about Food & Drinks
“hostess was rude” is about Service
“dangerous neighborhood” is about Location

We’ve considered a few algorithmic options to achieve our goals:

#1 Keyword String Similarity

We could use string similarity algorithms like Levenshtein distance to determine similarity between example keywords and potential keywords. This would allow us to match similar results, but would be limited to matching based on character/string similarity.

#2 Topic Modelling

There are a number of topic/keyword modelling algorithms used to extract keywords and topics — probability distributions over keywords — from a corpus of documents (TF-IDF, NNMF, LDA, etc). However, these models have a few shortcomings for our purposes:

• They tend to produce keywords rather than phrases, e.g. `”burger”, “amazing”, “rude”`
• They tend to produce topics that are pretty abstract
• They don’t let users easily (re)define their own topics

#3 Keyword Semantic Similarity

We could compute semantic similarity using word vectors, such as those created by the word2vec family of algorithms. This would let us match words based on similar meaning, which is far more interesting than matching on string similarity alone.

As a happy bonus, this should generalize pretty well due to the semantic embeddings that come along with word vectors, which means we won’t need many examples from a user to get acceptable results.

Model

One limitation of our setup is that we will have a very limited set of examples for any given topic, since they are user defined and we can’t aggregate them across users to obtain additional samples — users might use the same labels for different topics or different labels for the same topic.

To overcome this limitation we’re going to use a combination of unsupervised learning and a few labeled “training” examples.

We’ll start by using the word2vec family of algorithms to train word vector embeddings in an unsupervised manner. We could use a library like gensim to do this ourselves, but we’ll start by using the pre-trained GloVe Common Crawl vectors.

GloVe is an unsupervised algorithm that attempts to obtain high-dimensional vector representations of words using global word-word co-occurrence. This has been shown to encode interesting semantic information and to encode semantically related words nearby one another.

We’ll use SpaCy, which is a general purpose NLP tool which also happens to include pre-trained vectors for the most common English words using the GloVe Common Crawl.

import spacy

# We’ll use SpaCy which includes pre-trained vectors for the most common words using the GloVe Common Crawl

nlp = spacy.load(‘en_core_web_md’)

To get our limited training sets, we’ll ask our users to create topics. Each topic will have an arbitrary and non-semantic meaning — so “Food” could just as easily be labeled “Edible Things I Put In My Mouth Parts” without affecting the predictions.

We’ll also ask the user to provide a few example keywords when creating a topic — these will have semantic meaning and will be treated as training data.

# Something reasonable for restaurants

topic_labels = [
  ‘Food & Drinks’,
  ‘Service’,
  ‘Location’
]

# Chosen arbitrarily based on the first things that came into my head (or stomach, as the case may be).

topic_keywords = [
  ‘food drink burger soda pancakes wine delicious’,
  ‘service waiter friendly polite chef wait’,
  ‘location atmosphere bathroom parking sketchy’
]

# Parsings strings rather than lists is both faster and more convenient when using Spacy

We’ll then convert each keyword into a vector using our pre-trained GloVe vectors. For the sake of simplicity, we’ll compute the vector for a given topic as the vector average of each keyword example provided for that topic.

import itertools
import numpy as np

# Use pipe to run this in parallel

topic_docs = list(nlp.pipe(topic_keywords,
  batch_size=10000,
  n_threads=3))

topic_vectors = np.array([doc.vector 
  if doc.has_vector else spacy.vocab[0].vector
  for doc in topic_docs])

print(‘Vector for topic “%s”: topic_labels[0])
print(topic_vectors[0])

Output:

Vector for topic “Food & Drinks”:

[ -1.99757293e-01 -4.95044291e-02 4.21748608e-01 -3.01545769e-01

3.09107266e-02 4.76079166e-01 -1.30468145e-01 4.08424325e-02

6.72827214e-02 1.47339153e+00 -6.12631381e-01 2.56016135e-01

-3.29934269e-01 6.73128739e-02 1.51954994e-01 -4.45749998e-01

-2.42174357e-01 1.04534137e+00 -4.50572930e-02 1.16892839e-02

4.07283790e-02 -1.04680426e-01 8.87452587e-02 -1.93947569e-01

-3.77685726e-02 -2.78988570e-01 -1.41135286e-04 -1.57422870e-01

4.70718481e-02 -5.06019652e-01 4.60011438e-02 3.07148602e-02

3.20431173e-01 -5.58141470e-02 7.77551383e-02 3.35381418e-01

1.15111999e-01 -7.01131448e-02 6.48147091e-02 5.89464307e-01

-2.07138151e-01 -7.37772658e-02 1.20484233e-02 -1.74553558e-01

-2.96945665e-02 5.05793273e-01 -8.00428540e-02 1.77145407e-01

1.30204279e-02 -7.86484331e-02 -1.06742427e-01 -3.15071456e-02

1.59233902e-02 9.64338519e-03 4.88269955e-01 -3.58436137e-01

1.72668565e-02 1.02600284e-01 4.82039973e-02 -3.72299962e-02

3.17740709e-01 -3.54194850e-01 1.57416716e-01 2.81598002e-01

-1.08053572e-01 -6.99252903e-01 9.61262435e-02 -1.36746272e-01

-8.49143136e-03 3.90658587e-01 -2.69178320e-02 4.18035775e-01

3.34612578e-01 -1.56967431e-01 1.06249675e-01 1.39367491e-01

-5.79032823e-02 1.66077480e-01 -3.26235779e-02 1.19569138e-01

4.11198623e-02 -4.12609950e-02 -6.95311045e-03 -3.41599971e-01

-1.59764007e-01 -3.20679277e-01 7.01359689e-01 7.70343244e-01

-4.05881405e-01 -3.54143116e-03 -1.28352210e-01 -1.68865710e-01

2.51239985e-01 9.21018794e-02 -2.14748427e-01 2.37738281e-01

-2.64977992e-01 -3.45452875e-01 3.92649360e-02 -6.46310300e-02

-1.29251406e-01 -2.96629012e-01 -3.44895720e-02 9.56003147e-04

-1.64745092e-01 -7.11518586e-01 7.65848637e-01 -1.74950570e-01

4.49017256e-01 -2.62702137e-01 1.07751429e-01 -4.15087163e-01

-6.22012913e-01 1.89657174e-02 1.28729731e-01 -2.59919584e-01

-1.09734284e-02 -1.34277612e-01 -4.54222895e-02 1.64447159e-01

2.69114282e-02 9.61947292e-02 -5.46522848e-02 -2.83824265e-01

1.13672137e-01 -3.88755858e-01 3.15509319e-01 -1.80297300e-01

2.20131442e-01 2.98823565e-01 -1.13528572e-01 -5.05738616e-01

3.02138567e-01 2.84141570e-01 -1.96213856e-01 -2.65185744e-01

9.06198695e-02 1.20231286e-01 -1.03728421e-01 -3.46799999e-01

-2.12330008e+00 2.42902562e-01 4.97058392e-01 2.60201126e-01

6.59997091e-02 -6.70057178e-01 -2.64552295e-01 2.34475568e-01

4.19369996e-01 -1.52284861e-01 2.33055994e-01 1.43907562e-01

2.69406706e-01 2.22119704e-01 -5.21871373e-02 -3.12097996e-01

2.12987095e-01 -9.39349979e-02 2.47776866e-01 1.60665140e-01

-2.72208542e-01 1.13824569e-01 -1.62257464e-03 3.80442925e-02

-1.04599282e-01 -3.63481462e-01 2.22085626e-03 -2.33125553e-01

4.02804352e-02 -1.19491434e-02 3.09861422e-01 -9.49144438e-02

6.66061416e-02 -2.06918985e-01 -5.05372882e-01 -1.15404285e-01

3.73345688e-02 -3.09876710e-01 -5.23142749e-03 -5.57858825e-01

-1.80492282e-01 -6.31727159e-01 1.07501283e-01 -1.59387425e-01

-1.12959996e-01 -1.58670112e-01 1.60532430e-01 -1.89522784e-02

-1.14960477e-01 -2.46308297e-01 -4.13802564e-01 -9.76445675e-02

-9.78024155e-02 -3.85024279e-01 2.35258602e-02 1.18244573e-01

9.17275622e-02 3.78201455e-01 3.35558414e-01 -1.67783007e-01

-2.40880713e-01 1.93531558e-01 -2.04680730e-02 3.75754274e-02

1.30345717e-01 1.35562867e-01 -3.79882567e-02 5.69881439e-01

5.11336982e-01 -5.96181378e-02 -3.15410286e-01 4.35090326e-02

1.54755428e-01 -4.40605693e-02 2.15756893e-03 -4.81089950e-02

4.23218533e-02 -1.73465282e-01 -1.74352869e-01 2.25237846e-01

-3.22335571e-01 3.34743828e-01 -7.04478547e-02 2.57323831e-01

3.10993582e-01 -2.05346927e-01 -1.54695719e-01 -1.22790020e-02

-4.80933428e-01 1.85552999e-01 -2.15588585e-01 -1.99234277e-01

-1.04213424e-01 -3.06527138e-01 4.26714355e-03 5.76764420e-02

-5.67272902e-02 -2.77763575e-01 1.02616146e-01 -2.51384284e-02

-4.73474339e-02 8.15474018e-02 -4.45549399e-01 -1.92689419e-01

1.87552884e-01 4.16546583e-01 -1.19562864e-01 -2.89553314e-01

-4.33508843e-01 -1.89673707e-01 1.28984421e-01 -9.35430005e-02

-2.27030009e-01 1.26258001e-01 7.00331479e-02 4.80928868e-01

8.49688575e-02 2.26614382e-02 -6.28517047e-02 1.81602284e-01

-1.71440154e-01 -6.07371368e-02 -2.71877140e-01 -2.48359945e-02

4.60029915e-02 3.88630003e-01 -3.05292875e-01 2.19110399e-01

-4.55571860e-01 4.29314338e-02 -2.40779564e-01 2.37517320e-02

2.94728130e-01 -8.78202915e-02 1.24177136e-01 1.28934711e-01

-1.68483004e-01 2.99268458e-02 1.94610000e-01 6.84512913e-01

6.63699880e-02 -3.39112915e-02 8.31452832e-02 -2.30181292e-01

-4.54069301e-02 3.45917165e-01 6.70717180e-01 2.57638425e-01

-2.24785715e-01 4.64067161e-01 2.84794718e-01 1.54505715e-01

-1.14798136e-01 -2.35010241e-03 -3.97105694e-01 3.55972797e-02

1.92001194e-01 -6.37782872e-01 4.54465717e-01 2.23669693e-01]

Next we’ll create a set of keywords to evaluate. We’ll use short phrases with clear subjects, to match the sort of phrases that we extract elsewhere.

Note that we’ll attempt to categorize the entire phrase, but we could easily use SpaCy’s part-of-speech tagger or dependency parser to alter this behavior to only categorize the subject of the phrase.

keywords = [
  “pizza was gross”,
  “hostess was rude”,
  “dangerous neighborhood”
]

keyword_docs = list(nlp.pipe(keywords,
  batch_size=10000,
  n_threads=3))

keyword_vectors = np.array([doc.vector
  if doc.has_vector else spacy.vocab[0].vector
  for doc in keyword_docs])

print(‘Vector for keyword “%s”: ‘ % keywords[0])
print(keyword_vectors[0])

Output:

Vector for keyword “pizza was gross”:

[ -3.07331771e-01 1.55103326e-01 2.44910002e-01 -1.31743342e-01

4.82396632e-02 3.06213677e-01 2.29470015e-01 -2.10163340e-01

2.12949991e-01 2.06516671e+00 -3.66076678e-01 2.96839327e-01

5.71066625e-02 1.56943664e-01 -6.83133304e-02 -2.17026666e-01

4.02930006e-02 9.66080010e-01 -5.51763512e-02 1.13464333e-01

1.92884013e-01 -3.15896660e-01 1.07944004e-01 5.10730082e-03

3.64023328e-01 -2.12746665e-01 -3.01489383e-01 7.89169967e-02

5.63699901e-02 -1.79156661e-01 3.61913331e-02 1.38968438e-01

1.01356678e-01 6.31956756e-02 -1.47319987e-01 1.44793332e-01

-3.93940002e-01 1.06420666e-01 -5.57699986e-02 2.42561683e-01

6.34400025e-02 2.53916651e-01 2.57966667e-01 -8.25533345e-02

2.36996666e-01 3.65909964e-01 -7.43083283e-02 -2.39566732e-02

1.94116667e-01 2.29206681e-02 9.29993391e-02 1.36432335e-01

2.43066669e-01 1.65892005e-01 3.71261328e-01 -5.12073338e-02

1.41933316e-03 -1.32765338e-01 2.52993345e-01 -2.90699992e-02

6.18473291e-02 -4.20833612e-03 -1.10163391e-02 3.31276685e-01

-1.53233334e-01 -5.03459334e-01 4.59093340e-02 -1.09149992e-01

-2.21355006e-01 2.08036602e-02 1.08538993e-01 1.33806661e-01

-5.48633337e-02 -3.64141971e-01 -5.73766790e-02 -9.43079963e-02

-2.25765347e-01 1.03582002e-01 1.35770008e-01 5.03003299e-01

2.11973324e-01 1.95393264e-02 4.43670362e-01 -2.33676493e-01

6.77299947e-02 -1.72225654e-01 6.52773321e-01 9.27132275e-03

-2.81859994e-01 -2.78129667e-01 -2.46251658e-01 8.02833363e-02

-1.25803337e-01 -1.82291985e-01 1.84412315e-01 1.37389988e-01

-2.66779929e-01 6.47331297e-04 2.20299661e-01 9.65130031e-02

-2.56526351e-01 1.30429998e-01 -2.12066565e-02 6.56399950e-02

-8.05459991e-02 -8.10513318e-01 4.02724355e-01 -9.77643356e-02

4.11799997e-02 -1.69566676e-01 -2.37715319e-01 -3.85039687e-01

-3.17114651e-01 -3.18695337e-01 7.50343427e-02 -1.84946671e-01

2.24204823e-01 -1.98893666e-01 1.54987335e-01 -6.60933256e-02

6.90574646e-02 3.20089996e-01 1.00191988e-01 -1.31000996e-01

-4.71619993e-01 -1.18850000e-01 1.50769994e-01 -2.80072004e-01

-1.35944992e-01 2.89173990e-01 -8.97419974e-02 -2.09833995e-01

4.80733328e-02 2.60210007e-01 4.50200029e-02 -2.97439963e-01

-1.79190040e-02 1.66786671e-01 -5.72835319e-02 4.62800032e-03

-1.53313673e+00 -4.02713381e-02 2.71550000e-01 3.08136672e-01

-1.05099984e-01 -2.58963317e-01 -3.30703348e-01 8.64876583e-02

2.98854679e-01 -1.69403329e-01 1.56120002e-01 -1.19810365e-01

2.24843338e-01 -1.54283330e-01 8.21433440e-02 -1.99633315e-01

-6.35533333e-02 4.30456698e-02 1.03250004e-01 -1.90299992e-02

-3.01216662e-01 -1.88840985e-01 1.51473330e-02 -2.41750345e-01

-4.49030995e-01 -2.11429998e-01 1.81733325e-01 2.43699983e-01

2.61533320e-01 1.14367664e-01 1.38033181e-03 -9.19046700e-02

-3.34900129e-03 -3.40379685e-01 -4.85113353e-01 -2.79533267e-02

-1.48331001e-01 -5.87703288e-02 -2.43146658e-01 -4.48340029e-01

-6.26410022e-02 -7.14899972e-02 -3.63176495e-01 -1.11569673e-01

-3.05996686e-01 -1.97100043e-02 -1.31500012e-03 2.21910000e-01

9.21376646e-02 4.57619987e-02 6.03363216e-02 1.02366664e-01

-1.60293341e-01 -3.06829959e-02 8.82329941e-02 4.63753380e-02

5.50763309e-01 -1.24953330e-01 3.87399979e-02 -1.63186669e-01

4.95326705e-02 -5.50573319e-02 -2.74903327e-01 2.44253337e-01

8.36366639e-02 6.65899599e-03 -1.08050011e-01 4.09469336e-01

2.05704331e-01 2.67073307e-02 1.76953331e-01 1.47010908e-01

1.92899644e-01 -5.95433498e-03 2.82436669e-01 1.12086676e-01

-7.40966722e-02 -1.88463673e-01 4.98403423e-02 6.32300004e-02

-7.63773322e-02 2.57159680e-01 -1.27439991e-01 -3.29719990e-01

-6.39623255e-02 -2.39631340e-01 -3.91940981e-01 -1.91449914e-02

-1.42434999e-01 -8.85099992e-02 -6.45316616e-02 1.86150327e-01

1.26456663e-01 -3.40986639e-01 -5.71399927e-03 -7.51599967e-02

-1.27987668e-01 -2.08030999e-01 -1.51932344e-01 5.20363301e-02

-2.26926640e-01 -1.81716029e-02 -4.25270051e-02 9.84000042e-02

2.72754341e-01 9.22419950e-02 1.83922842e-01 -3.92813355e-01

-1.53714791e-01 1.65277675e-01 -2.62646656e-02 -7.51433372e-02

1.13676667e-01 -1.02407001e-01 -1.54999988e-02 1.53593317e-01

1.81893334e-01 9.06920061e-02 -1.74686704e-02 5.05600013e-02

-3.24999988e-02 1.75522998e-01 -4.99023318e-01 -1.44216672e-01

6.68657646e-02 1.00259997e-01 -4.78589945e-02 -7.56713375e-02

-2.05283299e-01 -8.25176761e-02 8.71933326e-02 -1.05793335e-01

-6.35133386e-02 -1.81401655e-01 -5.24166644e-01 -3.24446671e-02

-1.53711334e-01 -1.40116662e-01 5.49716540e-02 1.66408658e-01

5.43406665e-01 3.15673321e-01 2.32096668e-02 -1.31833404e-02

-5.18619977e-02 3.60150665e-01 -2.27033403e-02 1.52769998e-01

-2.25639328e-01 3.14107329e-01 1.09166004e-01 2.81147987e-01

2.82556683e-01 1.61386669e-01 -3.93966697e-02 -3.50790024e-02

-5.33403307e-02 -2.23663330e-01 1.18904330e-01 2.29429197e-03]

Finally we’ll compute a similarity matrix of each keyword to each topic.

Given the limited amount of labeled data available we’ll compute similarity directly using cosine similarity rather than trying to train a classifier.

Cosine similarity has been shown to work well for word vector similarity, so we’ll compute cross-wise similarity and then assign each keyword to the topic it is most similar to.

Read more about cosine similarity here: https://en.wikipedia.org/wiki/Cosine_similarity

from sklearn.metrics.pairwise import cosine_similarity

# use numpy and scikit-learn vectorized implementations for performance

simple_sim = cosine_similarity(keyword_vectors, topic_vectors)

topic_idx = simple_sim.argmax(axis=1)

print(simple_sim)

Output:

[[ 0.64263082 0.51295328 0.46764562]

[ 0.44271073 0.7184602 0.47380295]

[ 0.35327053 0.39581808 0.60309017]]

Results

for k, i in zip(keywords, topic_idx):
  print(‘“%s” is about %s’ %(k, topic_labels[i]))

Output:

“pizza was gross” is about Food & Drinks

“hostess was rude” is about Service

“dangerous neighborhood” is about Location

A few ideas for improving this further:

• accounting for the possibility that a keyword phrase may not belong to any provided topics
• allowing for the possibility of a keyword phrase belonging to more than one topic
• using alternatives to vector average to assign topic vectors

We could also improve performance — we’ve vectorized our implementation, but we are still CPU bound. We could build out a GPU version using something like TensorFlow to boost performance significantly.

In practice, we’ve found the results to achieve high precision and recall when compared to human labeled keywords using GloVe Common Crawl vectors.

Classified 1000 keywords in 84.58209037780762ms

Precision: 0.922503725782

Recall: 0.77375

Results:

Keyword                        Algo         Human

0 deluxe steak/lobster combo   **Food       **Food

1 dining room                  **Setting    **Setting

2 sauce option                 **Food       **Food

3 drinks                       **Food       **Food

4 delicious food               **Food       **Food

5 fat laden food               **Food       **Food

6 pasta                        **Food       **Food

7 mocha kahlua vodka           **Food       **Food

8 chicken Philly               **Food       **Food

9 Handmade horseradish         none         **Food

...

For small datasets performance is near real-time on quad-core i7 CPUs.

We’re also able to classify ~10k keywords per second on low-end cloud CPUs. That could be increased dramatically by running GPUs, where we’d have access to 2k+ cores instead of 8.

Using Word2Vec to Classify Review Keywords was originally published in ReviewTrackers Engineering, Product and Design Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.