From my response on the Yabbly Startup Survivor Challenge: What is the best advice you can give to a startup going through their first rounds of raising capital?
For a startup (to qualify for my own personal focus: a consumer-focused, pre-revenue, Internet or mobile-focused model) looking to raise their first chunk of funding, here are my key bits of advice:
Strongly consider debt financing. Under this model, there's no need to establish a valuation, and the mechanism and paperwork are relatively simple. At the first institutional financing, your debt holders convert into an equity position, generally with leverage that recognizes their early risk (interest and discount).
Choose investors wisely. Limit the number of participants. Put a cap on how much capital comes from "friends and family". Make sure your investors can help you in other ways (i.e. introductions, advice, etc.) besides capital. Finally, don't invite investors who aren't prepared to be comfortable if their investment immediately goes to zero.
Raise just enough. One of my former co-founders used to say "if you don't know exactly what you need the funds for, don't raise them". At the same time, make sure the funds you raise will provide you with the runway and resource you need to get to the next level.
Be patient. Even where you have willing investors, give yourself as much time as you can to set up and close a round, as it will invariably take longer than you think/want.
Don't be desperate. The best time to look for money is when you don't need it, pure and simple. Connect with investors long before you need to ask for funding.
It's OK to say no. I have turned away capital on only a few occasions. In one case, we walked away from institutional funding with great terms to continue our work on a shoestring with a bridge loan, as we had growing revenue. It turned out to be an incredibly lucrative decision for everyone.
From my response on the Yabbly Startup Survivor Challenge: What would you tell your 18 year old self if you could go back in time and give him/her some professional advice?
My son is less than a decade from this point in his life. Scary. Between now and then, I have some time to flesh out my answer! What I’d say is pretty simple:
Know what you want to do. Rather than following paths of expected or least resistance, take the time to speak with people, understand what they do for a living, and try to determine what you’ll be happiest doing. By the time I graduated college, my path of least resistance was to get my PhD and become a professor of English Literature; but at heart I loved building software, and I should have taken the time to understand how I could make that my life’s work. If we’re lucky, some of us find our way back to professional joy….
Take more risks. For whatever reasons, we tend to overestimate the possible consequences of taking risks. If your belly is full, you have a roof over your head, and you possess at least one marketable skill, then the worst consequence of failing is that you look for another job or, better, take another risk. Without risk, reward is by definition limited.
Own what you do, from the minutiae of the work all the way through its context in the broader business. Workers who can do what they’re told are effectively commodities, but real agents of change, who drive a business forward independent of their role or title, are those who have the highest chances for success. Be that worker.
Work with joy, or look for something else to do. We live in an age and a country where many of us have the opportunity to push beyond bloodless labor, to actively work with joy, and to create meaning thereby. Don’t miss that opportunity!
From my response on the Yabbly Startup Survivor Challenge: How do you think about building culture at your company? And how do you think “good” culture helps your company? Thanks!
In my experience, culture isn’t something that can be layered onto an organization. It’s stamped indelibly by the founders/leaders and the values they establish and live by. From a practical standpoint, founders, as I’ve said before, must have a set of operating principles that transcend the “what” of their products and business, and inform the “how” of their work. Step one is to literally articulate and know what these values are (think simple, informal statement or bullet points); step two is to continually ask whether the work you conduct lives up to those values (periodic check ins); and finally, step 3, as you grow, involves evaluating prospective new hires in light of those values.
Having “good” culture isn’t a choice; it’s hardwired into the DNA of the company, and its lines of force are mapped directly back to the leaders. The rest is window dressing.
From my response on the Yabbly Startup Survivor Challenge: What was your worst/darkest moment in your starup experience, and how did you get through it?
Now that’s a great question!
In the Lucky Oyster office, on the wall between our two whiteboards, we have a copy of Anna Vital’s “How to Never Give Up” infographic (seebit.ly/1fMDu8L). She qualifies the lowest point in the graph, “the dip”, as follows: “right before success, you will face the worst.” In our field, successes look like blazing flashes of light, but we all know that in reality they all go through dark, dark days, and generally just before their ascendancy to greatness.
My darkest moment in a startup came just shy of a decade ago. Because of disagreements with and between my partners/investors, we found ourselves with almost no operating capital, having walked away from a $4m investment. Because of this, I had to lay off three engineers, close up the office we had been subleasing, and I–the only full time employee remaining–moved my workstation onto a crowded conference room table in my Mom’s office. My partners, both incredibly talented product thinkers and deal makers, were not only upset with each other, but literally on two different sides of the planet, neither local to me.
Firing up that workstation, I realized that from that moment, I’d likely be the sole tactical driver of the business for quite a long time. And while I’ve always loved wearing many hats in a business, the idea that I was quite literally on my own, having taken a bunch of steps backwards from a traditional growth trajectory, was pretty devastating.
A few things kept me going. First, I truly believed that what we were doing was innovative, important, and could really enrich the lives of our users. I also continued to love the work: it was technically challenging, but in ways that were solvable with creativity as much as engineering horsepower. I also knew that if we kept at it, we could organically build a sustainable business, with great revenue and high margins.
For support, I also turned to my partners. And it turns out that making it through the worst is an incredibly powerfully way to cement and enrich working relationships. Both brought just what we needed at that point to the table: enough working capital to get us to a sustainable point; introductions to partners and advertisers; and much more. But really, it was their continued faith in me and the business that helped keep my spirits alive. I turned their faith into my mission.
For a long time, things were difficult. Every day, I sat at that workstation, and I hammered. If it needed to get done, it was solely up to me. And looking back, it was one of the most productive periods of work I’ve ever had.
Slowly, we got back on a growth trajectory. We brought on someone to help us operate, and then a business development resource. Our traffic and revenue grew. We licensed our platform to a large publisher. And our product footprint grew larger every day. In the end, we were acquired for more than the post-money valuation of the financing from which we walked away.
The story ends well, which is a Good Thing, but what I take away from those dark days is far more important: the knowledge that it’s ok for disasters to befall a business, and that contractions in the typical growth trajectory of a business can be leveraged to focus the team that remains, and slingshot the endeavor back into ascendancy and ultimately, success.
From my response on the Yabbly Startup Survivor Challenge: What’s been the most unexpected lesson you’ve learned in your current startup so far? Why do you think you it was hard to learn that lesson until this venture? What are specific actions, tradeoffs, or processes you are or will be implementing to fully leverage this new insight?
Two lessons really stand out for me.
The first is pretty simple, and it falls under the “many hats” rubric. In the past, when I’ve been a part of startups, I was always part of a pair or team that included people with formal training in business (read: MBAs). And so all of the thinking and work around corporate structure, fundraising, equity, etc. was something that naturally fell outside of my ken and scope. When starting Lucky Oyster, I thought that I really needed a “business partner” to start the company properly, raise seed funding, etc. That assumption turned out to be totally untrue. With a little smarts, some research, and a great lawyer, the process of papering a corporation, building a cap table, issuing board resolutions, raising money, etc. is completely doable. Turns out that work isn’t so arcane after all. Great surprise….
The second is much more complex, and it has to do with my understanding of what makes a “good” product. I’m still working through what it means, but the short version is that if you’re going to build a mobile product, no amount of consumer research you conduct to define a “great” product will prove useful; instead, everything comes down to the choice of the consumer to use–and more importantly, repeat use–the app. Unlike the Web, where we can strong-arm adoption through tactics like search, mobile apps need to stand alone, in an application space far more intimate than the desktop: the hand.
There are a ton of implications: if you’re going to be a great product “in the hand”, then things like the difference between a “fling” and a “tap” are viscerally important. Also, and here’s the key learning for me: the proof in the pudding is in the use of the product. This means building simple, and light, and quick, and getting the product into peoples’ hands, in the wild, as fast as possible.
If you’re going to try to build a great product for mobile, prototype and product are identical. This stresses measurement and observation of the app, far more than study, planning, and design.
In our first mobile product, the hard lesson we learned was that no amount of consumer research, independent of method or scope, could stand in for actually having the product in market. And so we’re now organized around evolving the product in market, as we actually gather insight from use: quick turns, an emphasis on simplicity, and a willingness to cut features instead of adding them.
From my response on the Yabbly Startup Survivor Challenge: What are the most common mistakes that startup CEOs make in their first six months of business?
Painful! Here are a half dozen missteps I've either made, been a part of making, or seen made. Hopefully this will save some trauma for others:
Don't - think for a microsecond that your view of the world will last. Everything you know about your product, your business model, and your customer base is subject to change. What this means, practically, is that you need to be prepared to shift, pivot, and evolve as you learn. Know that you will be wrong, and that it's OK. Don't go too deep until there's validation, and remember that until you have traction the world is only yours to READ FROM, and not yet to WRITE TO.
Don't - speak until you really have something to say. This goes for branding, promotion, working the press, etc. Nothing is more painful than having to go back to the world and tell a completely different story.
Don't - fight to carve up a pie that doesn't yet have fruit filling. Founders agreements and division of equity are a Difficult Business, but if you can't equitably figure things out and move on with joy, perhaps it's best not to go any further with that partner. One additional bit of advice here: don't establish a founding partnership with either a) no mechanism for control (even a 49/51 split can work), or b) too diffuse a mechanism for control (even splits among 5 partners, for example).
Do - act quickly to define and live your core values. A company's DNA comes from its founder(s), but they need to make their stamp as early as possible. When it's early, it's ok not to be able to clearly define what you're doing, but unless you can articulate how you're going about it, there's no seed of a culture.
Don't - ask customers to agree with your world view. By and large, customer research is a great thing, but it can set you up for failure if you're not very very careful. What someone says in response to a question is almost invariably meant to please the asker. The real truth value in customer research is only found in behavior in the wild; the rubber meets the road when (and how, and whether) a customer actually commits to using/buying the product.
Do - as a founder, know what game you're playing. Are you in it to build something cool? To generate buzz? To establish yourself as a CEO? To become part of the startup community? To build and be acquired? To grow a business organically? To sell clicks to the next guy for a penny more? To innovate? To prove something to yourself? Until you're honest about what your motivations are, I'd argue that your ability to build a real business is diminished.
The final bit I'd add is that while we all want to avoid making mistakes, it's essential to realize that the business of a startup is in fact making mistakes. If you look at truly successful companies, it's almost always the inevitable sequence of failures and pivots that has led them towards the light.
From my response on the Yabbly Startup Survivor Challenge: It's become extremely competitive to hire good engineering talent. What have you done to get engineers interested in your company vs. all their other options?
As an entrepreneur and CTO, I have for the past 17 years been hiring engineers, for teams as small as two, and as large as over 100. As an engineer myself, it's my sense that often, the things that interest us about a career opportunity are in fact hard-wired into the DNA of the company (culture, leadership), and not necessarily those things the company can willingly dangle in front of us (titles, positioning, compensation).
In fact, I'd go so far as to argue that you can almost always distinguish between great engineers and commodity writers of code by determining just what motivates them in considering a new role. But I'll return to that in a bit….
Based on my experience, and listed in order of priority, here are the key issues that I find will tickle the cerebral cortexes and stir the passions of hire-worthy engineers:
Technical Leadership / Culture. Engineers thrive when there's clear technical leadership, and when they can look to a leader who a) understands the complexities of their work, b) has a vision for what's being built, and c) provides the resources (often, literally the air cover) to help them succeed. To take this a step further, technical leadership needs to be recognized as a key "asset" or core aspect of the company's values for great engineers to be interested. Of course, in a startup, none of this may be present yet, and if that's the case, then hiring for technical leadership–as much as any specific technical skill–is how to present the opportunity.
Doing Things "Right". We engineers are, by and large, analytical types, and believe strongly in doing things the "right" way. Understand that almost all of us secretly fantasize about being an "architect", charged with understanding and defining the best approach to building complex systems. Companies that demonstrate to candidates that they will have the latitude to do things properly (suspending, for a moment, how that dovetails with the needs of the company) will be more likely to attract engineers.
Scale / Scope. Second only to our desire to see ourselves as architects is our love of building to scale and scope. Chat with an engineer for a few minutes about their interests, and see how little time it takes for them to utter the word "scale". Helping a candidate understand how what they build will either a) be of broad scope, or b) scale up dramatically, will allow them to imagine flexing their analytical muscles in a role.
Growth. To attract great engineers, you need to present ongoing opportunities for growth. Generally, this boils down to demonstrating a path that gives them more and more difficult and interesting problems to solve as the company grows. We all love designing and building big things, and are often less talented at day-to-day maintenance. In fact, larger engineering organizations sometimes stagnate, as without a clear business rationale for new development, engineers can make smaller tasks into larger challenges than they really are, for the sake of varying what they do.
All of this said, let me show you how understanding where a candidate sits vis-a-vis the above issues can help you determine, at least in the context of a startup, whether a candidate is truly a great fit for you.
A. Engineers who either don't value technical leadership or aren't willing to help supply it are, in my experience, just looking to be told what to build. Candidates need to demonstrate an understanding that technical leadership that can't be lensed through the company's product and business goals is effectively useless. If you're a startup, and aren't ready to hire a truly great engineer, then call a spade a spade, and find a contractor to help you build something limited and specific.
B. In the past half decade, the software writing world has become–at least in my opinion–too enamored of what I call the "priestcraft", i.e. the process by which we build, as opposed to the outcomes of what we build. Candidates who focus the conversation immediately on engineering process (TDD, XP, Agile, Lean, Kanban, etc.) might not be right for an early stage startup, in which everything literally depends on outcome.
C. The truth of a startup is that you don't really know whether your product, business model, or customer base will scale. And so an obsessive focus on building scalable software isn't necessarily the right match for an early stage company. Rather than looking for a we-built-it-to-scale-and-then-it-did story, look for candidates who can talk about scaling systems up on an as-needed, progressive basis.
D. It's one thing to present a newly-hired engineer with a bunch of options to build new technology. But even better, in terms of evaluating a candidate, is to understand ways in which they have actively sought out new opportunities to build things that drove company success (either to extend a product, further the business, or delight the customer base).
The final tidbit I'll share is that looking for "engineering talent", at least in a startup, might in fact lead you down the wrong path. Some of the most talented engineers I've ever worked with would seldom be consideredengineering talent, at least by traditional formal definitions. The engineers I look for are more well-rounded, creative builders. They often have backgrounds in the humanities, and/or are self-taught, and can think creatively about what you're trying to achieve from a product/business/engineering perspective.
As so often happens in R&D, following a single thread can take you somewhere special and all consuming. That's what has happened by looking into social discovery. I have committed to this effort, formalized a new company, Lucky Oyster, secured funding, and we are off to the races! Continue following this effort at both http://www.luckyoyster.com/ as well as http://blog.luckyoyster.com/. For a bit of background, have a gander at the piece in geekwire: http://www.geekwire.com/2012/exmarchex-exec-lands-cash-lucky-oyster-takes-bing-google-social-search/ . Now, to dive deep and discover pearls....
Study of ~1.3 Billion URLs: ~22% of Web Pages Reference Facebook
Key Findings
Based on a study of ~1.3 billion URLs crawled by Common Crawl in 2012:
22% of Web pages contain Facebook URLs
8% of Web pages implement Open Graph tags
Among ~500m hardcoded links to Facebook, only 3.5 million are unique
These are primarily for simple social integrations
Intro
Over the past two months, I've become very excited about what I call "social discovery": leveraging what a person's social network already knows to help them find and discover new ideas, places and things; and new technologies that make social networking more useful to learning about the world.
Based on some of this work, I believe the nature of the Internet is undergoing a paradigm shift:
From unstructured to structured content
From Web sites/pages to entities
From links to connections
In the old world, Web pages and sites were "about" entities, and search engines used calculations based on the link as a key signal of network-wide relevance. In the new world, Web pages are becoming ever more incidental; instead, nodes in the network (Facebook pages, LinkedIn profiles, Freebase entities, Wikipedia articles, etc.) represent entities, and are connected to each other and to people through meaningful connections ("like", "worked with", "is accurate", "recommended", etc.).
Increasingly, people and organizations will seek to write themselves not to Web sites, but to the big "platforms" (APIs) like Facebook and Twitter. And more and more, Web sites are being rewoven into those social networks, whether by simple inclusions of "like" or "+1" buttons, or through more complex reflections of social connection.
When I look at the data, it's pretty amazing. On Lucky Oyster, which is an alpha application for social discovery, it's not uncommon for an occasional user of Facebook with only 20 friends to be intricately connected with upwards of 20 thousand entities. Active users with around a thousand friends are consistently connected to well over a hundred thousand entities. I believe that reading this graph is different than reading the Web; it requires both a new mental model and new technology.
Social networking isn't solely about the people (although Wall Street may value it that way): it's about the interconnections between structured content, entities, and people. And in the long term, that fabric will be the legacy of social networking and the battleground for digital meaning. I call this emergent state of affairs "the Web turned upside down": the social fabric isn't incidental to the graph of the Web, but will increasingly be ascendent over it in terms of the richness and utility it can provide to us. Its structure and metaphors will eventually reshape the Web into something completely different.
The Experiment
Yeah. All of this is cloudy, at best, even if it sounds cool. So I started with a very simple question:
To what extent is the Web interconnected with the social "fabric"?
We can look anywhere online to see the evidence of this, from on-site elements such as the "like" button, the +1 glyph, or on-site widgets from companies like Disqus. But what are the numbers? I started with the big guy on the block: Facebook.
These days, answering this question is MUCH easier than ever, especially for a lone engineer working out of a studio in his back yard. Using Amazon Web Services, the data set from Common Crawl, and a little custom code, I examined roughly 1.3 billion URLs from an ongoing 2012 Web crawl. Without embellishment, here are the results:
Summary ---------------------------------------------------------------- Crawl age: 2012 URLs examined: 1,297,373,773 TEXT/HTML examined: 1,117,415,954 Pages that include Facebook URLs: 242,063,274 (21.66%*) Pages that include Open Graph Tags: 84,453,177 (7.56%*) * = percentage of TEXT/HTML documents Detail - Facebook URLs ---------------------------------------------------------------- Pages referencing Facebook URLs: 242,063,274 Total Facebook URLs: 471,013,958 Average Facebook URLs/page: 1.94 Unique Facebook URLs: 3,556,668 Top Facebook URLS: /plugins/like 15.69% /2008/fbml 13.45% /sharer 9.54% /share 6.69% /plugins/likebox 4.60% /profile 1.30% /home 1.25% /group 0.96% /widgets/like 0.73% /plugins/activity 0.43% /plugins/recommendations 0.35% Detail - Open Graph Tags ---------------------------------------------------------------- Pages with Open Graph Tags: 84,453,177 Top Open Graph Types: hotel 1.55% movie 1.31% activity 1.14% song 0.76% game 0.72% book 0.67% band 0.66% restaurant 0.52% actor 0.40% profile 0.38%
On a more mechanical note, here's a bit about how I gathered the above data. After some tinkering with Amazon's Elastic Map Reduce (EMR), I determined that something even simpler would suit my needs. It was clear that writing a bit of worker coordination code would be far more efficient and easier to debug than learning the ins and outs of the EMR product (read: Hadoop). So I built a very simple boss/worker system. Workers were essentially AWS EC2 nodes with a worker AMI (machine image); on startup, each machine would create two worker processes, each of which would pull tasks from a master queue. For the queue, I used beanstalkd, as the number of Arcfile (Web crawl archive) paths to be served was relatively small. Finally, the workers would post statistics to the same master server that ran the queue, sending data, counts, and tons of extracted snippets (in json) to a Web service built on Sinatra. All of this was written in Ruby, in 296 lines of code.
Huge thanks to Pete Warden for some of the Arcfile streaming code; to Web Data Commons for the queue suggestion; and to the folks at Common Crawl for providing an amazingly valuable service and data set. Here are a few tidbits about the work:
Queue service: beanstalkd Web service: Sinatra Cloud computing: Amazon Web Services (AWS) Arcfiles processed: 351,171 Total processing time: 2,634 hours Worker EC2 machine type: c1.medium Worker EC2 cost/hour: $0.165 Total worker cost: $434.61 Average processing time per Arcfile: 15.90 seconds Maximum worker node count: 99 Total calendar time: ~1.5 days Maximum coordinated throughput: 2.3 million URLs per minute
The key lesson I've learned from the exercise is that given the tools and data available today, either for free, or at very low cost, it's possible for anyone to work with relatively Big Data without too much weeping and gnashing of teeth. I feel it's also really important to note that from start to finish on this experiment, I spent a total of about 4 days, which is truly de minimus. From here, the system can be much improved, and the questions evolve in much more complex directions: working through the data is as simple as modifying the worker code, resetting the master server, filling the queue, and firing off a hundred machines....
Noodling
1. Although I'm tempted to make a statement about whether I think that roughly 22% of the Web (based on this sample) references Facebook is high or low, to be honest, it's beside the point. This experiment can be seen as the first of a set of snapshots I'd like to conduct every few months, to see whether that percentage is going up, down, or staying the same. My guess is that it's rising, and fast. If nothing else, it's taken roughly a decade for Facebook to not only accrue roughly a billion users, but to entangle itself in about a fifth of the Web. That's pretty interesting by itself.
2. More significant, in my opinion, than the extent to which the Web references Facebook, is the number of Web pages that actually implement Open Graph tags (~8%). This is a deeper level of integration, not really one that's required (anymore), and in essence provides a basis for Facebook to achieve indexable visibility into the broader Web, as well as to introduce to it some of the core concepts it uses to define entities. Much the same way that the Google Toolbar and its caching mechanism gave the search giant live glimpses of the Web as it was consumed by people, these snippets effectively position the Web as a live, visible extension of the entities Facebook is seeking to have users define (through pages and applications). If I had to guess, I'd say that someone realized that turning the broader Web into entity pages was futile, especially if people could be convinced to use the Facebook platform to make their own pages in addition to (or in lieu of) Web sites.
3. The integrations are, expectedly, filthy. Welcome to the Web, right? The Open Graph types are all over the landscape, with crazy variations rampant. This isn't really surprising, but it does point to something Facebook is going to need to deal with in terms of doing more than name search for entities: categorization. Here's a gem of an Open Graph type: "bestylish:shoes ecommerce". The Open Graph type "article" has about twenty different variations, including some very interesting misspellings. As another example, consider that right now, Facebook allows people to classify a page as either an "author" or a "writer". Let me know if you can help me understand that one....
4. Open Graph types are wildly diffuse. The largest category is "hotel", at 918,205. This says a great deal about the well-known aggression of online travel publishers, as that number represents many many more times than the total number of hotels in the world. At some point, though, if Facebook is to build its value on the richness of the entity, they will need to solve the suturing problem: determining which of those pages (Web or other) actually point to the same thing in the world.
5. The most chronic users of creative Open Graph types were Mahalo and Zillow, followed by the cluster of Mapmyrun, Maymyride, and Mapmywalk.
6. Some interesting (and amusing) top references to Facebook pages turned up (go Kev?):
7. There are about a quarter of a million inbound references to the Facebook search function (/search).
8. Although about a fifth of the Web (based on this sample) references Facebook, and despite there being close to half a billion references to Facebook URLs, there are only 3.5 million unique URLs in the sample set. The bulk of these are for Facebook-specified integrations (those that add social dimension to a Web site), as opposed to specific inbound URLs. My key takeaway here is that although Facebook may know about a sizable portion of the Web, the Web barely knows anything about what's inside of Facebook....
What's Next
This was just a first step. There are a number of improvements and other studies I'm itching to make. If anyone wants to contribute funds for processing time, I'd welcome it! Here are a few:
Study other social platforms. Compare and contrast penetration levels.
Look at the variety of Facebook integrations.
Index the Open Graph data in its own search engine, just for kicks.
Make the workers more efficient. My gut tells me there's room for 1.5x improvement in throughput.
Run at lower cost by using spot instances. It's already pretty cheap though.
Fix the character encoding errors that caused some of the processes to hiccup during the run.
Run this study semi-regularly, to look at changes over time.
For more information, feel free to contact me at matthew at zyxt dot com.
Our networks know far more than we'd ever give them credit for. For the next six weeks, my intent is to explore the intersections between semistructured content, social interaction, and network knowledge. It's a massive field, but largely untouched outside of the giants (G, F, B). I believe this research can lead to kinds of search we today can't even imagine. More to come!
Over the past six weeks, I've been exploring a theme I term "coordinated messaging". This means leveraging technology to make our real world lives more efficient and secure. In this vein I've turned on three experiments:
Reachable (http://reachable.me/) - a dynamic emergency contact system that helps deliver urgent messages to consumers by coordinating multiple contact channels, on both the in- and out-bound: Web, email, SMS, phone, Twitter and Facebook.
Toduo (http://toduo.org/) - pair productivity to help partnerships thrive. I built this primarily out of a personal need to help keep my own life partnerships on track, and it's turned out to be a life saver.
SaferDater (http://www.saferdater.org/) - automated check-in and alerting system for people heading into potentially risky situations. Think dating, climbing, hiking, road trips, etc.
There has been some great early feedback on these experiments, and for the next few months I've put them in the hands of colleagues to help understand how they should evolve, what direction they should go in, etc.
