Intercom's Paul Adams on product

Before joining Intercom he helped design vacuums at Dyson, helped design Gmail, YouTube and Google+, and then at Facebook he led their Ad Units team before becoming their Global Head of Brand Design.

I talked to Paul recently about the principles and practices he brought to Intercom from Facebook and Google, how and why he developed a 666 roadmap for the company, and what startups should be focusing on in this coming year. Take a listen below.

If you like what you hear, check out more podcast episodes. Or subscribe to the Inside Intercom Podcast on iTunes, Stitcher or over at SoundCloud.

If you’d prefer to read Paul’s insights, a lightly edited transcript of our conversation is below. Short on time? Here are seven quick takeaways from our chat.

1. Having unlimited engineers and designers at your disposal isn’t always a good thing. When you’ve limited resources at your disposal, it forces you to focus on what’s important.
2. Bigger teams and lengthy requirements are a surefire way to slow down product development. Small teams and shorter cycles on projects are some of the best ways to make sure you continue to build things quickly.
3. When you’re building a product, you have to balance the day to day to day activities with the long term vision, thinking in terms of six years, six months, and six weeks.
4. Getting the balance right between competing priorities in your product is only achieved by having a well defined roadmap, with clearly defined inputs.
5. Most companies focus on 10% incremental improvements. Aiming for a 10x improvement, ten times better than what exists today, can help redefine the problem entirely.
6. The experience of our mobile homescreen being a bank of app icons is dying. We’re moving towards apps as services.
7. When planning the year ahead, it’s worth ignoring end of year predictions of what’s to come. Instead, focus on the long-term, and how you can enact your vision.

Des Traynor: Today I’m joined by our VP of Product, Paul. For the benefit of our listeners who haven’t tracked your career as closely as I have, prior to Intercom you worked at Google and Facebook. You’ve worked on products like Gmail, YouTube, Google+, Google Maps, and Latitude. At Facebook, you were the product manager for Facebook’s Ad Units as the end user experience system, is that right?

Paul Adams: Yeah. At the time there were about five or six product managers in the ads team at Facebook. I understand now it’s far greater than that. There was four or five PMs for the advertiser’s experience – how you create an ad with workflows, analytics, things like that. Then I was the sole PM for the ad units which were the things the end users of Facebook would experience.

Des: On one hand I’m tempted to read something into the 5:1 ratio. But on the other hand, it’s actually admirable that they had anyone doing it, right?

Paul: At the time, yeah. I think there isn’t much to read into the 5:1 ratio other than there’s tons of work on the advertiser’s side. There’s a lot of complex historical precedents for the types of things you need in order to run ads across networks.

Des: You were effectively the good guy of the end user? You were making sure it wasn’t as bad as it should be?

Paul: Depends how you think about it. The other PMs who are listening to this would say they’re good guys too. They were helping advertisers make sense of something that was complicated and new. At the time this would have been 2011 or 2012. At the time Facebook’s advertising network ecosystem, the ideas the company had for ads, were pretty radical. For advertisers it was overwhelming. Since then the team have done a phenomenally good job of making it much easier to understand. They would say they are the good guys for the advertisers.

Des: Absolutely, lots of good guys :).

Paul: All good guys.

The benefit of limited resources

Des: Google and Facebook, some of the most popular products in the world you’ve worked on. Was there a significant difference in how a product was run between Facebook and Google?

Paul: They were definitely different. It depends how you think about it. Were these deliberate differences or functions of scale? The biggest difference for me was the teams I tended to work in at Google – I worked in the UX team at Google – were really big. Big by Facebook standards and big by Intercom standards. There would have been 20-30 in teams.

The vast majority of those would be engineers, there would be a couple of product managers, and maybe a couple of designers. At Facebook, the scale was just entirely different. The Ad Units team I was the product manager for had me, one designer and three engineers. At times we had four engineers.

Des: Spoiled.

Paul: Crazy days, yeah :). We mostly had three engineers and that was somewhat deliberate. You’re somewhat starved of resources in the hope that you would focus on the most important things. In my experience, if you give a team many, many engineers, such that the ratio of product management to design to engineering isn’t right, you will get people doing things that aren’t necessarily aligned with the vision or the product plan or the roadmap. The product manager can’t stay on top of many engineers who want to do good work and want to build things. The engineers want to be efficient with their time. They’re creative and so they will go and build things that may not necessarily be positive overall.

Des: You speak about a ratio there. Is that something you keep in mind? Has it got to do with how much work the PM can keep track of? Is there a golden ratio for you here?

Paul: I have a ratio. People would disagree with me on this. I’ve had this debate many times with many people. I should preface this by saying it really depends on what type of problem you’re solving. Some problems are computationally heavy. At Google, for example, some of the problems in search are very computationally heavy. There’s lots of engineers who are purely working on background infrastructure or writing algorithms.

Here at Intercom, the ratio we’re trying to employ is 1:1:5. One product manager, one product designer and then four to five engineers. When it gets to five engineers, PMs and designers start asking me about when they’re going to get help.

The 1:1:5 product team ratio

Des: Do you start thinking we need to break this team up into two sub-teams? Or does it look like an extra designer? Would you be happy to scale the whole thing up according to that ratio?

Paul: Yeah. I think it depends on the type of problem or team you’ve got. At Intercom, we’re still figuring that out I think to some degree. As a product gets bigger or as you expand your horizons for what a product might cover or entail, the team can be split in two. They would have sub-challenges within a central theme. If you do that, the risk is with individual teams, you’re splitting things up. You need someone who is gluing this all together.

There’s different ways this can work. Sometimes you can have a group PM type role, and then more junior product managers who are more executional in those multiple teams. That can work well if you’ve got a really good group PM, or someone who is strong at thinking strategically, horizontally and systematically. Or you can grow the team internally. At times when I worked on Gmail, there were two PMs who, between them, figured out how things would work. It was more of a partnership.

Small teams and shorter cycles

Des: Interesting. What, if anything, did you borrow or take inspiration from when you designed how Intercom built its product from Facebook or Google?

Paul: I like to think I took the best of both :).

Des: I like to think that too :).

Paul: There were things at Facebook I thought were phenomenally great. Things like smaller teams for example, or shorter cycles on project development. Facebook would typically move faster and build things faster. I think a lot of that was down to how their culture worked and how their teams were structured. The culture was very oral. At the time, at least when I worked there, people didn’t write stuff down. There’s cost to that too, but if you’re sitting around each other at the same desks, you’re talking everyday, you’re there everyday. You can get a lot done without having to write all the stuff down, by using whiteboards instead.

At Google, it was a bit bigger. The artifacts tended to be different. Google have this PRD process – product requirements doc – which is basically their project brief. In my experience they were long; many, many pages at times. I left Google seven years ago. I don’t know what it’s like today. As far as I understand, PRDs still exist, but I don’t know what length they tend to be written.

The longer the doc, the less it gets read. The longer the doc, the less it gets remembered. For example here in our product process, I employ a strict one page rule. When I see the equivalent of a PRD, the first point of feedback I have is give me the one pager. It’s kind of a similar philosophy to Facebook. If you’re starved of resources, you’ll focus. If you’re forced to limit the brief to one page, you will get much better at describing the problem you’re solving or the opportunity coherently. I think it’s just a much better way to work.

A one page Intermission document succinctly describes the problem we’re solving

Des: Did you take any inspiration from Google on how you set up the product team here?

Paul: I honestly took more inspiration from the way Facebook was structured. I think you can tease out why that is. It wasn’t that things at Google were worse necessarily. I think the types of problems we are solving and the types of problems Facebook solve are similar. We’re both building communication platforms, we deal with a lot of the same types of design problems. We both have a messenger, we’re both trying to build things inside a messenger. Whereas some of the things I worked on at Google were just bigger. The time frames were typically longer so I guess that changed how you work. If you have a bigger product, a bigger product release with a longer time frame then I guess the artifacts tend to change.

Where will your product be in six years?

Des: That makes sense. One cornerstone you outlined recently, of how you think about product teams, is this idea of a 666 roadmap; thinking in terms of six years, six months and six weeks. Could you talk us through what that’s about?

Paul: It sounds catchy, 666 :). It’s proving to be incredibly useful for all our team. I learned a version of this at Facebook, and evolved it and changed it for our benefit here. When I was working at Facebook, some of the product management team talked in terms of two timelines. They talked about twenty years and six months. The idea was that twenty years was your vision. It was your vision for the future, how you thought the world would have changed in twenty years time and how you may fulfill the mission you’ve set yourself.

Twenty years is way too long to be pragmatic. To make it pragmatic, realistic and actually get things built, six months was the time frame to work towards. You could build over the next six months heading for this twenty year vision. Over the course of those six months, things will change, and it was a rolling timeline. As you get three, four months in you might make plans for the next six months.

At Intercom, we’re a startup. It’s different. Twenty years as a cycle for startups is probably too long. It depends what you do, but for us certainly I think twenty years is too far ahead for it to be in any way useful. Six months is pretty long as well. Six months in our life is a long time. We get a lot built, shipped and released in six months.

I changed the timelines to 666 – six years, six months and six weeks. Six years is not a prediction of technologies. It’s not what you think will have happened technologically over the next six years. It’s actually how the world changed over that period of time because of what you did.

In other words, if you weren’t around, if your company wasn’t around, your vision would never come to pass. The world would look different. Our six year vision is how the world will have changed because of what we did. That’s what is inspiring about it. We’re enacting the change. The change isn’t just going to happen because a bunch of people invented new technologies.

Six months is then our concrete plan towards that six-year vision. Six months is a good time frame for us to think about. We’ll generally be a similar size in terms of our teams and employees over a six month period. Beyond six months I think is bad. I often say a two year timeframe is the worst. There are exceptions to this of course, like with everything. Hardware for example, things that have longer production cycles. With software, I think two years is terrible. In two years time, it’s far enough into the future that it’s not particularly visionary, but it’s also too far ahead to really have a concrete plan.

Two years from today, we’ll see two new Android versions, two new iOS versions. We’ll also see potentially new hardware from both Apple and Samsung or Google. It just would look different. If we had a two-year plan two years ago, there would be no watches or any of that kind of stuff going on. It just means you get circular; it’s chaotic.

I think six months is as long as you should think ahead if you’re a startup. Six weeks is just our nuts and bolts, dialed-in version of what we’re building and shipping. If you had a six-year vision and you can map out the next six months, everyone knows where we’re headed. Six weeks is the day-to-day, step-by-step progress. The march towards that plan.

The balancing act of product management

Des: It’s interesting. Six years is quite a long time. It’s long enough to think of these mammoth changes to how a task gets done or to what it is that users are trying to do. Whereas six weeks is very much incremental; let’s add bits and pieces here. How do you like your PMs to balance the idea of “I want to redefine what the product is” to “We’d better add this button”?

Paul: We’ve developed a process. It’s basically a balancing act. If you try and do this in your mind, in my experience it won’t go well. You will overcompensate for some things versus others, you will forget things. It goes without saying that the job of product manager is an extremely hard one. You’ve got to keep so much stuff in your head at all levels.

You’ve got to be able to think really strategically and long-term. You’ve got to be able to think really tactically on a day-to-day basis. And you’ve to deal with everything in-between – issues and bugs, latency, speed, new features, improvements, radical new things versus iterative things. The way we’ve done this is we’ve got five inputs to our road map, five explicit inputs. And we balance them.

The five inputs into our product roadmap

We’re extremely research driven so there’s just one input of the five that’s not research driven. That input is things we think are cool and exciting. There’s going to be no basis in research. It’s things that we just think would be interesting. Usually the reason we think it’s interesting is because we’ve read lots of blog posts about it.

Des: There’s just no formal research I guess.

Paul: Exactly. The research is almost done subconsciously in your brain through osmosis, and then just chatting to people. Things we believe in is one input.

The second input is iterating recent product. In my experience, this is something you need to do deliberately or you just won’t. It’s so easy to ship something and forget about it. Ship something, move on; the shiny new ball syndrome. Our philosophy here is we ship to learn. We’ll ship and then we’ll figure out if it’s good or bad. Did it actually solve the problem we identified early on? We’ll set time aside to iterate.

Des: The way I phrase that for people is every feature you ship comes with its own roadmap you have to manage as well. Your product might now have data visualizations, but now you have a data visualization roadmap of all the things you need to add to the data visualizations feature. I think a lot of people forget that, and they get hungover on celebrating yesterday’s shipment. Rather than thinking about today’s new feature request.

Paul: Yeah, totally. That’s definitely the way I think about it as well. How good are we at removing things? I think we’re not bad. We do remove features that don’t get used. Generally speaking, I think it’s true of almost every piece of software that they get bigger. They just naturally get bigger. You build more than you take away and there’s an art to trying to add more power without adding more complexity. Which is a whole other thing. Typically people build more and so it gets more complex. You do actually inherit a whole bunch of new usage patterns that never existed before. Now there’s X number of people using this new thing we built and we need to talk to them too.

Our third input is dedicated to feedback we hear from customers. This is heavily research driven, heavily qualitatively driven. Our customer support team is an incredible asset to us here. We think of our customer support team quite strategically in that regard. They’re not just there to service customers and keep them happy, though that’s clearly an important thing. They’re also there as an amazing input into our roadmap. When they’re talking to customers through Intercom, they’re talking to customers everyday. They’re tagging conversations with what team it relates to, whether it’s a usability problem, a feature request, or some area of confusion. They’re tagging all these conversations and then our product managers are synthesizing that. Our research team helps as well. Then they basically build a hit list of things that our customers need.

The important part in this roadmap is that we don’t just do what customers are asking. We prioritize them based on our own vision and mission. If you have this six-year vision, it’s easy to look at a bunch of feature requests and actually decide to not do some. Our customers don’t have the same insight into what our vision is as we do, and so we often decide to not do things that are heavily requested.

When we make that decision, we’ll actually then tell customers that we’ve no plans to build that thing. The other important caveat is often people, users of your product, don’t know what they need. I often say this to our team. Customers are experts in their problem. They’re not experts in the best solution. They will often describe their problem in terms of a solution, so they’ll ask you for what they think they need. What we’ll often do is get our product managers to go back to those people and start talking to them. “Hey you asked for this feature. What are you trying to do? Why did you ask for that?” They’ll actually get to the root of the problem. Multiple layers deep of investigation basically.

A whole other input is customer requests. As Intercom gets bigger, as we continue to grow and grow quickly, we get bigger customers. Different types of customers that have different needs than other companies that have used Intercom historically. You have a whole track for that, a whole track for how does Intercom work on scale. Bigger companies with bigger teams, more users, it’s just different. We’ve a whole track dedicated to that. For a long time I think we got away with designing Intercom for ourselves. The companies that use Intercom are very similar to us. We’re very attuned to the problems they have. As we’ve grown, our user base has diversified. Now we need to realize that we’re not actually experts in all the problems that other companies have.

The fifth input is around quality. Quality includes things like bugs, issues, performance, latency. They’re the five inputs [into our product roadmap]. The balance to this is basically making sure that we’re we’re making progress on all five.

The one thing I would say in case anyone listening wants to go set a 20% rule for each of the five inputs, is we oscillate. We absolutely oscillate and that’s the right thing to do. We’ll go through a phase of building new product and then our issue count will rise. We’ll go through another phase where we’ll focus on getting that count down. We’ve had issues in the past where it oscillated too much. Now we’ve got a way better balance. If you look at our roadmap and it’s documented, you will see that every project has one of these five inputs written beside it.

Are you focusing on 10x or 10%?

Des: It’s interesting the way you describe the things we believe versus working on a feature we just shipped. You can totally see the bonds between trying to come up with something that’s 10% better than what’s live versus something that’s just absolutely better. To do this stuff, the things we believe type stuff, do you encourage the PMs to have a vision of what a fundamentally better Intercom looks like?

Paul: Yeah, this is really interesting. Ken Norton is a partner at Google Ventures, and he was a product manager at Google before that. He gave a talk at Mind the Product, a really great product conference if you haven’t heard of it before.

Ken gave a really interesting talk at last year’s conference. The gist of it was the difference between 10x type projects or companies and 10% type projects and companies. 99% of the time people end up heading towards the 10% improvement versus the 10x improvement. The 10x is literally ten times better than what exists today. The reason for that is risk. It’s risky to go 10x because if you fail, you’ve just failed.

Two projects with their expected values in yellow. Credit: Ken Norton

Whereas 10% is safe. You can add 10%, get 10% better and you can have a very predictable track of work. Generally it’s hard to totally screw it up. The difference is the 10% companies are probably on some local maximum. They’re just iterating towards something that’s going to have diminishing returns over time.

Whereas the 10x companies are ones that will actually disrupt the market and come up with something radically different. If you have this explicit mindset of a 10x versus a 10% when you tackle the same problem, you tackle it from the 10x point of view and you think absolutely differently about it. Totally different. All the assumptions and existing ways of working will go out the window. You’ll radically rethink ways in which it might work, challenge all assumptions and go back to first principles. We use that phrase at Intercom, go back to first principles. It means tearing away all the existing constraints for how things actually work and starting from scratch. Getting to the root of a problem and then working from there.

Des: What’s an example of this? When you think about it in terms of Intercom. What’s an area we see 10% things and 10x things?

Paul: One example is Colin Bentley, our product manager for our Engage product. Colin’s done some really good 10% improvements recently. A few months ago we launched a feature called delivery windows. Before, when you sent a message via Intercom, it sent whenever the criteria matched a user. A user has done X or Y, the message got sent and they got it straightaway. A 10% improvement there is a delivery window that doesn’t send on Saturdays or Sundays. Or doesn’t send at 2am in the person’s local timezone. They’re simple, little, incremental 10% improvement. But Colin is not only thinking about that, he’s thinking about a 10x improvement. What’s a 10x improvement for a better way for a company to send messages to users? Then you start thinking about radically different things.

You don’t start thinking about a delivery window setting on a message that turns off Saturdays. You start thinking about artificial intelligence and machine learning. Could we take inspiration from things like ‘if this then that’? Could we actually write algorithms to figure out when to send that message? A 10x improvement would be we’ve built algorithms, we’ve used AI, we have a machine learning ecosystem. It just works by magic and you should trust us. That’s 10x.

Colin, again our product manager for this area, is doing some 10% improvements but he should be also thinking, and is thinking, 10x. 10x is where the real value lies in the longer term you know? At Intercom we see ourselves very much as a long-term company. We plan to be around for a long, long time, and so 10x is critical to our future.

The end of apps as we know them

Des: Changing tack a bit, a year ago you wrote a piece which caused a little bit of uproar where you said it is the end of apps as we know them. I think a lot of people missed the second clause there. That was about a year ago. It’s interesting to look back at it and ask how far do you think we’ve come along this way?

Paul: It is fascinating actually, it’s a fascinating question. I had to write a second, follow-up blog post called it’s not the end of apps.

Des: That was an awkward day on the index page of the blog :).

Paul: It was an argument that, at some level we have reached bankruptcy in terms of apps. This idea was that that these apps on our home screen, apps nested in folders of apps, is crazy. It’s not a good experience. Nobody, from the start of the iPhone looking forward or in 2020 looking back, nobody would be proud of this outcome.

That’s not a sustainable model. All of the ecosystem has been built up around this. The cottage industry, if you like, around the app store is all optimized for getting that download, getting that button on your screen. What I was positing at the time was this will change. I was looking at the evolution of the notifications panel on phones.

Notifications are starting to become much richer in terms of the content that’s being delivered, much more interactive. The older model was that notifications were signposts.You’d get a notification that’s deep linking you into that app. The notification does nothing. Whereas these newer notifications, the newest version of Android at the time, you could actually retweet something from the notifications panel. Or you could reply to something. That’s directionally the future more so than apps.

I actually referenced Google Now a lot. I thought Google Now was a great model for this. Potentially I would imagine, this is total speculation, but that Google Now and the notifications panel in Android would merge. They’re effectively trying to do the same thing. The notifications panel will suffer from volume at some point so they need to rank it. Google Now is trying to do that, bring information to you before you know you need it, by knowing what you like etc.

The idea I was expecting was Google Now would evolve really fast. I thought my experience of Google Now would be that it would full of third party apps, full of third party content. I thought I’d be replying, texting, writing and taking actions, with many app workflows in each Google Now card. That’s what I thought would happen.

I thought at the Google I/O just gone, we’d see that. I thought we would see some radical step change in how Google Now works. That didn’t happen, I’ve no idea why. Google Now has improved in a whole bunch of different ways but it’s just been slower than I thought. On the other side though, things happened I had no idea were going to happen at all, but are directionally supporting this idea that apps and the app icon are coming to an end. Or changing at least.

An entire Uber workflow embedded within Foursquare Ken Norton

What you’re starting to see is apps integrating with other apps. Today for example if I open Foursquare, I can call an Uber from Foursquare. The way it works is this little SDK and Uber is basically embedded in Foursquare. You might not have Uber, but you have Foursquare. You tap Uber in Foursquare, and Foursquare they have enough context and data to actually order you an Uber. This to me is a glimpse into the future.

There’s a few interesting things you can pull out of that. One is you’re thinking about services and not apps. At this point, Uber isn’t an app. Not in the traditional sense. They probably don’t give a monkeys at this point if the app is downloaded. They care if an Uber gets ordered. Foursquare users could keep ordering Ubers in Foursquare and never download the Uber app. And Uber probably doesn’t care.

Des: It’s interesting thinking will change engagement metrics and thoughts around is my product doing well? Even that question isn’t relevant in that world.

Paul: Absolutely. This is a relic of the powers at play and the ecosystem that exists. App owners typically obsess about app store reviews and that’s all to do with further downloads. Rather than try to get you to use it more, they actually optimize to get your friend to download it. Now we’ve seen that the app store is filled with millions of apps, with hundreds of thousands of users, and close to zero engagement. There’s lots of statistics on this. I think the average person uses eighteen apps a week and they have way more than that on their phone. They have like fifty to a hundred apps on their phone.

Des: One thing that stands out for me there is the idea that Uber, in that example, exists in another app’s context. If you know what I mean? Foursquare’s bringing something to the party. It’s saying, “Here’s where you are are. Here’s where you want to go.” Uber is living inside that. You think that model of apps borrowing context from each other is going to be the new way? It used to be people talked about it as being deep linking or whatever. How do you string apps together or whatever. This is actually a deeper than that right? This is how do you make the functionality of an app live inside another app?

Paul: Yeah, totally. I guess websites, the original structure of HTML, is a good example. All links did was point you to another place, like a signpost in the road. It’s like there’s a fork in the road and you can take one road, or you can take the other. The signpost has no opinion about which road you take. It doesn’t even know where you want to go.

Deep linking suffers a little bit from that. It’s trying to replicate links and signposts whn the deeper integration is way more interesting. Take Button, for example. What Button do is basically provide buttons [within apps]. They provide that Uber button in Foursquare, for example. What Button actually do really is much more of a back-end service.

I’m not entirely sure the technologies of this, but basically they have SDKs. In theory Uber can give Button a bunch of context and Button can pass that on to Foursquare. Whole workflows could be developed here. If you order an Uber in Foursquare it actually lets you choose the car. Suddenly now parts of the Uber workflows are inside Foursquare. You can extend that then to context. Suddenly the Foursquare experience of Uber could be totally personalized based on your usage of Uber elsewhere. That’s fascinating.

Des: This idea, this is akin to what Fred Wilson wrote when he was talking about contextual run times right?

Paul: Yeah. There’s been great reading towards the end of the year. Benedict Evans wrote a fantastic post called 16 Mobile Theses which is just sixteen things that are happening in mobile. Some more speculative than others. Then Fred Wilson wrote a follow-up post [in response], as one of Ben’s theses was that there’s going to be a new runtime.

The app store model that exists is not sustainable. You can look to Asia for a lot of this; a lot of this is already built inside WeChat. WeChat is an entire ecosystem of services and apps running inside WeChat. If you open Maps in We Chat, for example, you can order a taxi from the map. They’re not really apps anymore, their services. There’s now a new runtime. They’re running in another environment; that could be a platform or it could be a different app. Like a Maps app, who knows?

Fred’s point was that it will just be entirely dependent on context. The context of what you’re currently doing will inform the types of new services you get. Of course we might get this wrong, such that the service you actually want isn’t being provided in that runtime. It’s being provided in some other run time. They probably do all sorts of stupid things like shopping and geo-targeting. I think again the world of advertising might get this terribly wrong before they get it right. It will be really interesting to see how this evolves.

The real impact of long term thinking

Des: For sure, it’s a really interesting trend. I think the thing I like most about it is it provides these clean break points in workflows. If you know the next logical step is to book a restaurant, you now have a way to facilitate that within your product. Whereas before, it’s just like well off you go. Some other product now takes over. It’s interesting.

As startups look towards 2016, what should they think about in terms of their product teams for the year that lies ahead?

Paul: What I try to avoid, and my advice to other people is to avoid getting wrapped up in all these ad-hoc lists. Top ten new technologies in 2016. Ten things to watch out from Apple in 2016. Unless there’s some really good analysis and insight by a really good writer, they’re a waste of space :).

Instead, I’d go back to what we we talked about earlier, the 666 vision, or along that kind of general timeframe. If you have this longer term vision, the change you want to enact in the world, then that helps you get away from all these technologies of 2016. Virtual reality will come up, as Oculus is going to launch to the public early next year. But we didn’t know what would happen with iPad or iPhone and this is going to be similar. Putting in place some product strategy, putting in place some six-month roadmap around VR is probably not smart unless you work in gaming or something that’s clearly going to be disrupted by this idea.

Having that six-year vision is way more important. My advice to people as we go into 2016 is actually to think much more long term.

Des: Cool. I think we should probably leave it there and go back to work :). Paul, thank you very much.

Paul: Cool, thanks for having me.