Joining Appear Here as CTO

Brand and Product

Appear Here's very clear and focused mission resonates with me because they want to create a world where anyone with an idea can find space to make it happen. They achieve this by bringing together a community of brands, entrepreneurs and creatives in the world's best cities. They already have 80,000+ global brands and creative entrepreneurs, 10,000,000+ sq ft of spaces and 3 offices globally. Brands and entrepreneurs can use the Appear Here platform to find and book short-term spaces such as high street boutiques, market, shopping centres and shop shares in London, Paris and New York.

Company Culture

From the very first interview to signing my contract and officially joining, the team at Appear Here have built a company that continuously upholds these values:

We're Hiring

We're hiring talented people to help make this ambitious vision a reality. We're currently looking for Software Engineers and we will soon be hiring for other product and engineering roles as we grow.  If you're interested in joining me and the rest of the Appear Here team, feel free to reach out to me directly (via Linkedin or Twitter) and we'll have a coffee to chat through what we're up to.

I'm looking forward to taking on this new responsibility as Appear Here's CTO and working with the team to drive the business forward. 

Recent Press

• Appear Here, a marketplace for short-term retail space, raises £12M Series B
• How an 'Airbnb for retail' is bringing entrepreneurs back to the high-street
• Appear Here - 'the Airbnb for retail' - eyes big brand budgets with launch of Global Projects team

Building a "Job Finder" skill for my Amazon Alexa Device

Growth

According to a recent NPR and Edison Research Smart Audio Report, 5% of the 1,620 surveyed respondents owned an Alexa device (Echo or Echo Dot) and 2% owned a Google Home device. Even more revealing was the fact that 42% of Smart Speaker owners said that "their Smart Speakers are essential to their everyday lives". By any stretch, Smart Speakers have reached a significant level of product/market fit and in a little over 2 years Amazon Alexa devices are leading the pack and growing at a rapid pace:

Business Insider: Amazon Echo sales and stats - Dec 2016

Skill

I decided to build my first Alexa skill to better understand the underlying Alexa Skills Kit that powers all Amazon Echo devices to give users this new intuitive voice interface. I was particularly interested in voice-user interface (VUI) design and how easy it would be to go from idea to building and then deploying a new skill. For the actual implementation, I decided to use the new Flask-Ask framework by John Wheeler to build the skill along with using Zappa to deploy my Python code into AWS Lambda. 

I settled on a simple idea for a "job finder" skill that allows users to answer 2 simple questions that Alexa asks them about which city and job role they were interested in. The skill would then return the most relevant job listings that had been posted in the last 24 hours according to the answers given. I imagined users waking up in the morning with their coffee in hand and asking their Alexa "job finder" skill to get the latest updates for their ongoing job search. If the skill responded with some particularly timely and relevant jobs, the user could then decide to immediately open their laptop and apply for those jobs or, if not, the user could simply continue to enjoy their coffee and resume the job search later on in the day.

Implementation

I spent a few evenings coding up the "job finder" skill's Python backend and configuring the interaction model (the intent schema and sample utterances) to get it working locally. I ended up with a single job_finder.py file for the bulk of my application logic which is only 116 lines of code and a template.yaml file that contains a number of the templated launch, answer and re-prompt responses which are required for the skill. All-in-all the learning curve was reasonable and most of the learning came from understanding the new type of interaction model set out by the Alexa Skills Kit.

Demo

As of writing this post the "job finder" skill is being reviewed by Amazon's Alexa's team and therefore is unavailable at present to enable on your own Amazon Echo device (the skill should be certified in a week or less). In the meantime I've recorded a demo using Amazon Alexa Testing Tool called Echosim.io:

Learnings

• I've capped the number of jobs Alexa responds with to a maximum of 5. I think this is a manageable amount but given that Alexa might misunderstand the job role given by the user, it could be frustrating to have to listen to all 5 jobs if they are based on an incorrect interpretation. Therefore I would potentially improve the skill's VUI to either have Alexa repeat the job role specified by the user before all 5 jobs are listed out OR I would pause Alexa after the first job listed and ask the user a yes/no question on whether Alexa should continue or not.

• I've purposefully kept each job listing very brief so it's easy for users to consume while listening but it might be useful for users to get more detailed information. I could improve the skill's VUI by asking a follow-up question at the end of listing the 5 jobs to know whether or not the user wanted more details about any or all of the jobs listed.

• I'm using the AMAZON.ProfessionalType intent slot and this is currently only supported in the US. Therefore when the skill is certified by the Amazon team it will only be available on US based Alexa devices. I've asked about UK support for the AMAZON.ProfessionalType intent slots but have not yet received information about when UK support for it will be available. 

• Analytics are very important for knowing what is and is not working from a user's perspective. I often use tools like Google Analytics for websites and Mixpanel/Amplitude for mobile apps which have been very insightful to better understand user behaviour. For my Alexa skill, I'd like to add in something like Dashbot analytics to get a window into what users are and are not doing with the skill.

• Most importantly I would like to find ways to improve the VUI for subsequent invocations of the "job finder" skill. If a user has already performed a prior job search then I'd like to be able to have a search saved against their user profile and then have the skill look it up and ask the user whether or not it should be re-used. This will reduce the number of questions Alexa asks the user upon each new "job finder" skill invocation. Such functionality can be accomplished by identifying users by their UserId obtained from the session and then querying a database for prior jobs searches to re-use.

---

Update

1. I mentioned implementing analytics within the skill previously. I've since integrated VoiceInsights analytics from VoiceLabs.co to begin receiving data for individual and aggregate user sessions across metrics such as usage, pathing, speech and retention. I'm finding it more valuable compared to Alexa's skill metrics data that are provided by default.
2. My "Job Finder" skill is now live in both the US and UK markets:

Improving On-Site Search Functionality For GrowthHackers.com

Back in 2013 when GrowthHackers.com started gaining prominence and was regularly used by thousands of growth engineers, I started noticing that their on-site search functionality needed some improvement as relevant content was hard to find. I knew the small GrowthHackers.com team were working hard to design and deliver important features that were growing the community, so I wanted to help out by articulating the problem and devising a solution that would be easy for them to implement and could almost immediately be leveraged by the GrowthHackers.com community. 

Here is the short presentation I created and sent to Sean Ellis. It was subsequently used to improve their on-site search and is still used today by the GrowthHackers.com community (note that instead of using Swiftype they went with a similar product called Algolia):

Improving Search on GrowthHackers.com from Andrew Thompson

The Swiftype based search for GrowthHackers.com that I setup when I created the above presentation is still working today (give it a try):

Examples of Mobile First Development

We all know that developing for mobile is different than developing for the desktop but how exactly is it different? I'm deeply interested in how a mobile product needs to be structured in a fundamentally different way than a desktop product in order to thrive. It cannot simply be a slimmed down, feature minimal version of a the desktop or tablet version. It should not feel as if its missing critical features or useful add-ons simply because they couldn't fit into the mobile format.

Various concepts have emerged for how to approach mobile app development. One revolves around mobile apps being remote controls for real life. Another is about mobile apps being useful for a user while they wait for something (i.e. in a line-up or in an elevator). In order for that to happen a user should be able to launch the app and perform some task within 30 seconds to a minute. MG Siegler of CrunchFund also had this to say about building for mobile:

"Don’t build an app based on your website. Build the app that acts as if websites never existed in the first place. Build the app for the person who has never used a desktop computer. Because they’re coming. Soon."

Some companies have built very compelling business models that fit well with this mobile first, quick and effective/remote control paradigm. Users are responding well by engaging with and being retained by these mobile apps due to their simplicity. The following examples show how mobile apps can reduce inherently complicated tasks down to very simple actions which are fundamentally different from anything we've seen previously on the desktop.

1. Hotel Tonight

Hotel Tonight is a mobile-only app where users can book last-minute hotel deals. Hotel Tonight has simplified booking a hotel room down to only a few essential actions without degrading the experience to the point where it feels limited. Here is the user flow from initial launch through to booking confirmation:

1. During launch the mobile app retrieves the hotels on offer given the user's current location. Although this may take a few extra seconds, it presents the user with the exact information they are interested in right when the app loads (the user is not required to type anything).

2. The user is then presented with the hotel selections in a scrollable list with the 3 most essential details displayed: photo, price & location. The app also provides some other useful data like the type of hotel experience (Solid, Basic, Luxe, Charming, Hip) and a rating by other Hotel Tonight guests. This information makes it very easy to select an appropriate hotel for the night.

3. Once a hotel has been initially selected, some further details can be reviewed such as additional photos, information about the hotel itself and its exact location on a map along with the final price.

4. The final screen allows the user to easily confirm the dates, price and credit card to be used for the transaction.

From start to finish this process only requires 3 simple actions: a single hotel selection, an initial booking of the room and finally a confirmation of the booking details. Hotel Tonight has given travellers the ability to easily choose and book a hotel room from their mobile phones. The whole process from start to finish feels uninhibited by the mobile form factor it actually thrives within it. Its because of this that the mobile app thrives and continues to delight users.

2. Car2go

Car2go is a vehicle sharing service paid for by the minute where vehicles can be picked-up and dropped off in different locations. The primary way to find and reserve a vehicle is via its mobile app. Given the nature of the service offered, it needs to take seconds (not minutes) to book a vehicle via the app. Here is the user flow from initial launch through to vehicle reservation:

1. The mobile app launches fairly quickly, determines the user's current location in order to position the map correctly and starts retrieving vehicle locations. Again this presents the user with the exact information that are looking for without any interaction after launching the app.

2. Vehicles begin populating on the map and the user can then zoom in and out to find the vehicle closet to them or simply select a vehicle.

3. Once a vehicle has been selected, the blue vehicle marker expands to show 3 additional bits of information: license number, distance away and gas available (indicated as a percentage). Although this information may be helpful in some circumstances it can be presented in a different and this third step can potentially be removed completely:

• The license number is unimportant to the vast majority of users unless a user has forgotten something in a vehicle and is trying to find it (but this is a very rare case).
• Knowing the distance to a vehicle isn't as helpful as knowing the approximate time it would take to walk. A vehicle may be 562m away but how long would that take if the user walked there? A separate interaction with the marker (such as a "2-second hold") could display the walking time from the user's current location therefore removing the need for the distance measurement in the expanded marker.
• The gas available is the most helpful but it could be more easily displayed so that it can be compared with all other vehicles. By displaying something visually on each vehicle's non-expanded marker (possible a textual percentage of even a level indication), this again would avoid the need to click on the marker to find out how much gas is available.

4. The final screen allows the user to review the vehicle's gas available, cleanliness, street address before confirming the reservation.

Again from start to finish this process only requires 3 simple actions: a single vehicle selection, reviewing some of the vehicle's specific information and finally a confirmation of the reservation details. As outlined above this 3-step process can be further simplified to just 2 steps by removing the expandable marker step and simple going straight to the reservation confirmation screen. Having said this, even with 3 steps this mobile app by Car2go is very efficient to use - a vehicle can be reserved in under 30 seconds.

3. Uber

Uber seamlessly connects a user needing transportation with a taxi driver. Uber, the company, does not own any vehicles and does not have any drivers on staff, instead they provide ride-logistics to both users and drivers in order to match supply and demand more effectively. Ultimately Uber wants to get users a taxi in the shortest amount of time and give them the best experience while helping drivers anticipate demand and therefore maximize the earnings per shift. Here is the user flow from initial launch through to taxi request:

1. During launch the mobile app determines the user's location in order to display the correct map along with taxis on the following screen. 

2. Taxis begin populating on the map but they also update in real-time as taxis move about through the streets or get requested by other users and are no longer available. This gives the user immediate feedback about each taxi's relative speed and direction along with the approximate supply of taxis in the given area. All a user has to do is position their pickup location, review the approximate wait time and then tap the "SET PICKUP LOCATION" button.

3. The final screen allows the user to review the pickup location, credit card to use and approximate wait time before confirming the request.

From start to finish this process only requires 2 simple actions: choosing a pickup location and confirming the taxi pickup request. Uber has made the process of booking a taxi on their mobile app as simple as possible and it works phenomenally well for users.

Classifying Knowledge for Engineering and Product Development

When designing and building a software product there are many things that individuals or teams know and there are also things that they don't know... this is pretty obvious. However this simplified distinction is missing some of the inherent complexity about knowledge that we can or cannot know. Donald Rumsfeld describes this larger epistemological concept, which can be quite complex, in a pretty straight forward way:

There are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don't know. But there are also unknown unknowns – there are things we do not know we don't know.

These three ways of classifying knowledge can be very helpful during product development for both engineering and product teams. Not only does it help to communicate the various types of things that we may or may not know but also helps to showcase that there are things that we don't even know that we don't know - i.e. concepts, tools, processes, best practises that might exist already but we don't even know about them and therefore don't know to look for them (which I will explain in more detail below).

Mike Gagnon

1. Known Knowns

"Known knowns" are those things that each of us has previous experience with or those things that are held as best practises within the industry that we know about already. Here are some for engineering and product teams:

• Engineering: Computer languages that are closer to the bare metal of a machine (e.g. C/C++) are generally faster then those languages that run on a virtual machine (e.g. Java, .NET, Python... etc) given the same algorithm and data.
• Product: When designing conversion pages/screens, each additional step (button click, user input, screen swipe.. etc) in-between the user's entry point and the objective for them to accomplish, results in some trivial or significant amount of drop-off. This can be easily seen in a conversion funnel by measuring and then observing the individual percentage drop-offs between each successive step.

In the engineering case you usually don't need to write the exact same algorithm in multiple languages and measure the execution time but you can be confident that as a general rule of thumb a C/C++ algorithm will be slightly (or maybe even significantly) faster than a virtual machine based language running the same algorithm. Testing always makes sure this assumption is valid and the results can sometimes conclude the opposite but engineers perform so many performance or functional assumptions when writing code that validation for each and every one is not realistic.

In the product case you can be almost certain that the removal of a single non-essential step will increase the conversion rate by some amount (what exactly that amount would be is something that would have to be measured). For example, many conversion flows for social networks include the option to import contacts in order to find your friends/colleagues/acquaintances... etc so that you can connect or follow them (Facebook, Linkedin and Twitter do this). But in other products its less about satisfying the core functionality of the product in terms of connections and more about it being a virality growth hack to acquire more users. Importing contacts in the first case is obviously vital to engage and retain users in a social network but in the second case the step could be removed at the cost of acquiring less users (i.e. no virality). Removal of this step would almost certainly increase the overall conversion rate (due to the step no longer causing drop-off) but usually the increased amount of users, due to the contact import, out weighs the amount of users who drop-off at the contact import step. Therefore it's usually desirable to leave the contact import step in the conversion flow even though is decreases overall conversion rates by a slight amount.

As a final note, the better you are and the more experience you have, the more "known knowns" you accumulate. Because of this you work more efficiently since you have access to a wider array of expertise that you otherwise wouldn't have had. According to Malcolm Gladwell's "10,000-Hour Rule" written about in his book, Outliers, it may take 5 years or more (40 hours/week over 5 years is 10,000 hours) to accumulate enough knowledge to become an expert in any given field.

2. Known Unknowns

"Known unknowns" are those things that we may have some theory for or gut feeling about but don't actually know what the correct approach or answer might be. It might even be that you know that something exists but don't know much else about it. Essentially its being aware of your own ignorance about something. Many good senior engineers or business analysts face these types of issues on a day to day basis and are pretty good at either asking questions and listening to others, performing research to uncover the right approach/answer or, if not available, they experiment or prototype until it becomes more evident what the right approach/answer might be. Once this is done "known unknowns" turn into "known knowns" which is obviously a good thing.

For many things "known unknowns" are similar across engineering and product teams. A software engineer or business analyst might know that something exists which could help improve the product (say a new Python library or integration with another product) but not really know much about it. All they would have to do is begin researching it and given sufficient time they will figure out what they need to.

There is of course a specific area where these teams differ. The worlds of engineering and product start to diverge for "known unknowns" when predictability is accounted for. Software systems are inherently predictable, they generate the same output given the same input - they're built this way to manage complexity. There are things that seem random but they are usually the result of unexpected user input, actual random number/string generators and/or partial system failures that cause intermittent behaviour. The advantage of predictable systems is that various solutions can be re-used across domains and if something has been used once before chances are it can be used again in a different context and the benefit of a lower learning curve can be leveraged. There is also the benefit of a tangible "done criteria" for software systems. If a module within an application was supposed to parse a CSV file and insert each row into a database, then it's pretty easy to determine when all the work is done either by observing the results or writing some unit/integration tests to verify things. The consequence of this can be seen with all the open-source libraries and tools available that are built by one set of engineers and then used by thousands of others engineers for their own applications in a different context.

For product teams the inherent challenge is that users behaviour differently and are very hard to predict. Users behave differently from across different products but even more unsettling is that their behaviour changes over time on the same product. Essentially users are unpredictable and things that have worked in the past may not work in the future. It's analogous to the Law of Shitty Clickthroughs: what works today may not always work tomorrow as users learn and respond to your own product and all the other products that they use. On top of this its never as easy to simply mimic/copy an existing product's features and expect the same results. Engineering teams can use the same open-source library and be pretty confident that the results will be the same. However product teams who decide that a given feature might be worth mimicking/copying for their own product are really gambling on the idea that their users are the same type of users as the other product - and this is never usually the case. For example: If you're building some type of social network you're most likely observing what Twitter, Facebook, Linkedin, Pinterest... etc are doing but simply turning your UI into a Pinterest type feel or adding hashtags may not have the same results as those products had due to the fundamental difference that their users are not the same as yours.

Having said of this, engineering teams are able to turn "known unknowns" into "known knowns" often times more easily than product teams by researching and spec'ing out the design. Even before anything is built it's usually apparent that the given solution will work with enough engineering time (scalability aside). For product teams its a constant challenge to start with "known unknowns" and turn them into "known knowns" after thoroughly researching possible options or coming up with theories of how users might behave. Until the intended product feature addition or change is fully implemented (or, if you're lucky, maybe just some small component of it that users interact with), its almost impossible to know how users will behave.

Conclusion: For product teams "known unknowns" usually stay that way until you've actually shipped your product and see how users are using it. It's only at this stage that "known unknowns" become "known knowns".

3. Unknown Unknowns

This is the scary stuff. "Unknown unknowns" are the things you don't even know that you don't know about (actually they're not that scary because you're actually completely ignorant about them). They're not even on your radar and you don't even know they exist. The dangerous part with "unknown unknowns" is that even with enough time or energy they won't magically turn themselves into "known unknowns". In the engineering case this is like not even knowing that an entire field of academic study has worked on and solved a particular problem with an elegant algorithm that if you just knew about you could use in your application and solve you and your team hundreds of hours working on your own solution. In the product case its like being completely ignorant that another business somewhere in the world has a competing product that is vastly better than yours even though you and your team might have done some extensive market research.

So what do you do with "unknown unknowns"? Well here is the only thing Mike Gagnon thinks you can do: 

The best you can do with “unknown unknowns” is be aware that the category exists and maintain an open mind. This way when information presents itself to you, you can cognizantly realize that it was an “unknown unknown” and then you’ll either be in the “known knowns” or “known unknowns” category.

This is why being a prolific reader is so important. It feeds your mind with a ton of new information, ideas, concepts and solutions that you had no idea existed previously. Everything you read, are told about or experience first hand has the opportunity to identify "unknown unknowns" which at the very moment no longer remain as "unknown unknowns".

My grade twelve english teacher once told our class that we should not spend the rest of our lives reading books that agree with our current belief system but rather we should deliberately read ones that disagree with it so that we grow and change for the rest of our lives. I don't think I really had any idea what he was talking about back then but some how more than decade later I still remember those words and I now understand what he means.

4. Unknown Knowns

This one wasn't mentioned by Donald Rumsfeld but its worth mentioning briefly. Scholars of logic will have noticed that there are two words with two possibilities each which translates into 4 possible outcomes. Mr. Rumsfeld mentioned three of them and obviously didn't talk about the forth but its worth asking whether or not "unknown knowns" are even possible.

It turns out that the well known psychoanalytic philosopher Slavoj Žižek extrapolated a forth category which he obviously called "unknown knowns". He said that "unknown knowns" are those things that we intentionally refuse to acknowledge that we know. Slavoj even wrote an essay on the matter but it speaks more about politics than the underlying concept of unknowingly knowing something. Essentially its those things that we actually do know but we either vehemently deny them or even go so far as to suppress the knowledge we have about them.

The engineering and product teams that I've managed have been highly collaborative and open to exploring new ideas even if that meant redoing and/or throwing out inferior work. So when one person found a solution that could significantly change or alter currently held assumptions, it was always encouraged to bring that to the team. In light of this there was never much incentive to suppress knowledge about something across the team in order to avoid telling the truth even if it hurt to tell it.

There could of course be a case where any one individual would have some incentive to suppress the knowledge they had about something and therefore harbour an unknown known. This is obviously a reality but building the right culture with the right people helps immensely in avoiding this behaviour outright or at the very least discourages it.