Book review: Sprint (Part 3 – Day 2)

September 3, 2016 marcabraham1 Comment

Once you’ve set a target as part of Day 1 of your sprint, the next step is for you and your team to look at solutions. On the second day of the sprint, you’ll be coming up with solutions, and sketching them. This day consists of two key activities: (1) review ideas to remix and improve, and (2) create solution sketches to feed into your plan for a prototype and customer testing.

Remix and Improve

In “Sprint”, Jake Knapp, John Zeratsky and Brad Kowitz suggest a good technique to collate and assess ideas: Lightning Demos. With this exercise, your team will take three-minute tours of their favourite ideas or products: from other products, from different domains, and from within your own company. The idea here is to encourage the team to throw everything in the mix, but to do so in a short and snappy way. Each person who has suggested an idea will do a three minute demo, showing the team what’s great about his or her solution. As a facilitator, you might want to use a timer to make sure each team member sticks to the their three minute time slot.

The key thing with these three minute ‘lightning demos’ is that you capture the big ideas from each presentation. Start by asking the person who’s doing the tour, “What’s the big idea here that might be useful?” You can then make a quick drawing of this big idea, write a simple headline above it and add the source underneath. I’ve included an example of a way to capture big ideas in Fig. 1 below.

Fig. 1 – An example of capturing ‘big ideas’ from lightning demos, by Karsten Neben – Taken from: https://medium.com/@karstenn/what-we-learned-in-just-5-days-our-design-sprint-report-b9ada5b7f19a#.27wb5fv4e

Lightning Demos

Sketch

In the afternoon of the second day of your sprint, the focus is on coming up with solutions. Instead of doing collective brainstorming sessions – which in my experience run the risk of becoming shouting matches or can be dominated by very vocal people – Knapp, Zeratsky and Kowitz suggest each team member coming up with ideas on their own. People will work individually, thinking about and sketching solutions. I’ve included a simple example of a sketch in Fig. 2 below.

The sketches that people create will act as an important driver for the rest of the sprint. On Wednesday (Day 3), you’ll critique everyone’s sketches and pick the best ones.

If you’re worried about the quality of your sketches, don’t! Knapp, Zeratsky and Kowitz introduce the four step sketch technique. This approach makes it easy for everyone to take some rough solutions and turn them into a detailed solution sketch (see Fig. 2 below):

Notes – As a first step, the team walks around the room and takes notes from looking at all the post-it notes, whiteboards, flip-charts that you have collated over the first day and a half of your sprint.
Ideas – Each team member individually will look at his or her notes and jot down rough ideas, simply filling a sheet with doodles, headlines, etc. The aim here is not to come up with fully fledged ideas or solutions. It’s purely a way for each person to drop down their thoughts.
Crazy 8s – Crazy 8s is a fast-paced exercise. Each person will take his or her strongest ideas and rapidly sketches eight variations in eight minutes. What I like about Crazy 8s is that it stops you from dwelling on your first possible solution for too long. Instead, the eight minute deadlines forces you to quickly decide whether to move on from your first reasonable solution or to stick with it but iterate (see Fig. 3 and 4 below). I’ve found Crazy 8s to work particularly well if you end up sketching several variations of the same idea, exploring alternative versions. Similarly, you can use Crazy 8s to refine a marketing headline or messaging.
Solution sketch – The solution sketch is each person’s best idea, put down on paper in detail. Up to this point, each team member will have worked individually on creating notes, ideas and Crazy 8s, and won’t have shared anything with the rest of the team. This all changes with the solution sketch; each solution sketch is an opinionated hypothesis for how to solve the challenge at hand. These sketches will be looked at – and judged – by the rest of the team. They will therefore need to be detailed, thought-out, and easy to understand (see Fig. 5 and 6 below).

Once each team member has put together a solution sketch, the sprint facilitator will collate them all and put them in a pile. The team will only be allowed to start looking at these solution sketches on the third day of the sprint.

Fig. 2 – Four step sketch technique – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

4-stage sketch

Fig. 3 – How to do Crazy 8s – Taken from: “Sprint”, pp. 112-113

Each person begins Crazy 8s with a single sheet of letter-size paper.
Fold the paper in half three times, so you have eight panels.
Set a timer to sixty seconds.
Hit “start” and begin sketching – you have sixty seconds per section, for a total of eight minutes to create eight miniature sketches.
Go fast and be messy: As with the notes and ideas, Crazy 8s will not be shared with the team.

Fig. 4 – Crazy 8s example – Taken from: https://www.fastcodesign.com/1672917/the-8-steps-to-creating-a-great-storyboard

Fig. 5 – Important rules to keep in mind when creating a solution sketch – Taken from: “Sprint”, pp. 114-118

Make it self-explanatory – Your solution sketch needs to explain itself. Think of this sketch as the first test for your idea. If no one can understand it in sketch form, it’s not likely to do any better when it’s polished.
Keep it anonymous – Don’t put your name on your sketch, and be sure that everyone uses the same paper and the same black pens.
Ugly is okay – Your sketch does not have to be fancy (boxes, stick figures, and words are fine), but it does have to be detailed, thoughtful, and complete.
Words matter – Strong writing is especially necessary for software and marketing, where words often make up most of the screen. So pay extra close attention to the writing in your sketch. Don’t use “lorem ipsum” or draw those squiggly lines that mean “text will go here.” That text will go a long way to explain your idea – so make it good and make it real!
Give it a catchy title – Since your name won’t be on your sketch, give it a title. Later, these titles will help you keep track of the different solutions as you’re reviewing and choosing. They’re also a way to draw attention to the big idea in your solution sketch (see the example in Fig 6 below).

Fig. 6 – A solution sketch from Blue Bottle Coffee’s sprint; each sticky note represents one screen – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

Sketch example

Main learning point: The second day of the sprint is very solution oriented. Instead of long brainstorm sessions, the day is filled with more individually oriented activities, encouraging team members to think about ideas and to come up with their own solution sketch.

Related links:

Book review: Sprint (Part 1 – Setting the stage)

August 29, 2016 marcabraham1 Comment

I personally find it very encouraging to see that more and more companies go down the route of experimentation and continuous discovery. Businesses are starting to realise that committing to a single solution upfront and implementing it in the hope that it will be successful can be a very risky strategy. “Sprint – How To Solve Big Problems and Test New Ideas in Just Five Days” builds on this change by introducing the concept of a 5-day sprint in which to identify problems, explore possible solutions AND get feedback from real customers.

Jake Knapp and two of his colleagues at Google Ventures, John Zeratsky and Braden Kowitz, have successfully applied ‘sprints’ for a wide range of companies, helping the likes of Pocket and Blue Bottle to tackle difficult problems in just five days. This is how the five days are broken down:

Monday (day 1) – ‘Start at the end’; agree to a long-term goal and pick a problem to solve during the sprint
Tuesday (day 2) – Review and improve existing ideas and sketch possible solutions
Wednesday (day 3) – Select a solution to focus on and create a storyboard
Thursday (day 4) – Build a prototype, a realistic ‘facade’
Friday (day 5) – Learn through customer interviews

Sprint 1

Fig. 1 – Steven Nguyen “Reflecting on our first design sprint” – Taken from: https://sprintstories.com/reflecting-on-our-first-design-sprint-2d58519eefad#.ej6ivw4ma

The “Sprint” book contains a wealth of great techniques to utilise as part of a sprint. I want to do it justice and will probably devote a couple of posts to this great book. Before delving into each of the days of the sprint, let’s start by looking at ‘setting the stage’ before kicking off the sprint. It’s important to have the right challenge and the right team before you begin a sprint:

Challenge – As readers of my posts might know; I’m quite obsessed about understanding the problem(s) worth solving before exploring solutions. I therefore believe that picking the right problem or challenge to solve is absolutely critical to a successful sprint. Knapp, Zeratsky and Kowitz suggest three challenging situations where sprints can help: high stakes, tight deadlines or when you’re simply stuck.
Team – The key thing when assembling a sprint team is to get a ‘Decider’ in the team; someone who’s in a position to make important decisions. This can be the CEO or another important stakeholder. I like how the book provides a number of arguments one can use when a Decider is reluctant to get involved in the sprint (see Fig. 2 below). You should end up with a well balanced team, made up of people who can implement as well as subject matter experts (see Fig. 3 below).

On top of picking a team, it’s also important to have a designated facilitator who can manage time, conversations, and the overall process. Naturally, this can be someone from within your company or someone external. For example, I know lots of digital agencies that facilitate sprints as part of a piece of work for their clients. As much this is beneficial to the client, this also helps the agency by creating a shared and robust understanding of what’s going to be built and why.

Fig. 2 – Get a Decider (or two) involved – Taken from: “Sprint”, pp. 31-32

Rapid progress – Emphasise the amount of progress you’ll make in your sprint: In just one week, you’ll have a realistic prototype.
It’s an experiment – Consider your first sprint an experiment. When it’s over, the Decider can help evaluate how effective it was.
Explain the tradeoffs – Show the Decider a list of big meetings and work items you and your team will miss during the sprint week.
It’s about focus – Be honest about your motivations. If the quality of your work is suffering because your team’s regular work schedule is too scattered, say so. Tell the Decider that instead of doing an okay job on everything, you’ll do an excellent job on one thing.

Fig. 3 – Recruit a team of seven (or fewer) – Taken from: “Sprint”, pp. 34-35

Decider – Examples: CEO, founder, product manager, head of design
Finance expert – Examples: CEO, CFO, business development manager
Marketing expert – Examples: CMO, marketer, PR, community manager
Customer expert – Examples: researcher, sales, customer support
Tech/logistics expert – Examples: CTO, engineer
Design expert – Examples: designer, product manager

Main learning point: I recommend everyone doing a ‘sprint’ before committing to a specific solution. “Sprint” is a great book, with a lot of helpful guideance as to how to best solve big problems in five days. I’d argue that some of the techniques to use as part of sprint shouldn’t be constrained to a 5-day period or at the start of a piece work; I’ll outline in the coming posts how some of the sprint exercises can be used on a continuous basis.

Sprint 2

Related links for further learning:

Looking at key omni-channel analytics – Part 1

December 13, 2014 marcabrahamLeave a comment

Over the past few weeks I’ve been learning about retailers and how they sell via a multitude of channels. The next thing for me now is to learn about some key omni-channel analytics. Let’s start with some questions to ask when measuring omni-channel retail and marketing:

What is the impact of online channels on offline and vice versa? – Given the fluid nature of consumer decision-making, alternating between online and offline, it’s important to measure the impact of online activities on offline and vice versa.
What does the conversion path look like? – How and where do we convert people into paying customers? Where do we lose people and why? Which channels do contribute to conversion and to which degree?

I’ll start by looking at the impact of online activities on offline conversion. I learned an awful lot from a 2008 blog post on tracking offline conversions by data guru Avinash Kaushik. Before I delve into some of Kaushik’s great suggestions, I want to take a step back and think about potential things to measure and why:

What is the impact of online channels on offline conversion? – As a product person, I’m keen to understand the relationship between online activities and actual purchases in-store. This understanding helps me to focus on the right online and offline elements of the value proposition, comprehending which things can be optimised inline to achieve a specific outcome in-store.
How do I best measure revenue impact of my website or mobile app in an omni-channel world? – For example, I’ve got a nice eCommerce site or app with a decent amount of traffic, 20% of which gets converted into actual online purchases. However, what happens with the remaining 80% of traffic that doesn’t get converted? Is my website or app delivering some value to this 80%!? If so, how? Can we measure this?

Now, let’s look at some practical tips by Kaushik in this respect:

Track online store locator or directions – If I track in an analytics tool the interactions with the URL for Marks & Spencer’s store locator, I can start learning about the number of Unique Visitors that are using the store locator in a certain time period (see Fig. 1 below). In addition, I can look at the number of visits or visitors where a certain post code or town has been entered into the store locator. I can take this insight as a starting point to learn more about the people within a certain geographical area that have a tendency to use the Marks & Spencer site and its store locator. Once a user then goes on to click on “Show on map” or “Enter an address for directions to this store” you can make some inferences about the user’s intentions to actually visit the M&S store in question.
Use of a promo code – Using an online voucher or promo code is an obvious way to combine online tactics with offline conversion (see a John Lewis example in Fig. 2 below). One can use the promo code as an event in an analytics tool and capture data on e.g. the number of codes or vouchers exchanged in-store vs the number of vouchers sent. I guess the only downside is that you’re unable to capture many interesting insights if a user doesn’t redeem her voucher or code.
Controlled experiments – Running controlled experiments was the bit in Kaushik’s piece that intrigued me the most. The idea behind these experiments is to validate retail ideas in the real world (the same as “experimentation” in a ‘lean’ context, which I’ve written about previously). As Kaushik explains, “the core idea is to try something targeted so that you can correlate the data to your offline data sources (even if you can’t merge it) and detect a signal (impact).” I’ve included some prerequisites for successful experiments in Fig. 3 below. One of them is to isolate the experiment to different states that are far from each other. As Kaushik explains, this way you are isolating “pollutants” to your data (things beyond your control that might give you sub optimal results).

Main learning point: Learning about how online can affect offline conversion felt like a good starting point for my getting a better understanding of the world of omni-channel analytics. The next step for me is to find out more about the impact of offline on online conversion: how can we best measure the impact of what happens offline on the conversion online?

Fig. 1 – Screenshot of the results of Mark & Spencer’s store locator

Fig. 2 – Sample John Lewis voucher – Taken from: http://www.dontpayfull.com/at/johnlewis.com

Fig. 3 – Some points on prerequisites on controlled experiments by (online) retailers:

Clearly defined customer segments of a decent size to quantify the impact of the experiment.
Design the experiment in such a way that the results can be isolated and compared in a meaningful way (e.g. IKEA umbrella sales on a rainy vs on a sunny day).
Random selection of customers in the control group (who get the current offering) and the treatment group (who get the experimental offering).
Clear assumptions and hypotheses which underpin the experiment.
Create a feedback loop which allows you to measure or observe how customers respond to different experiments.

Related links for further learning:

Priya Prakash explains about Design Principles at Mobile Academy

October 22, 2014 marcabraham1 Comment

As part of the Mobile Academy curriculum, I recently attended a class by Priya Prakash on “design principles”. Priya is a very experienced designer and has founded Design for Change, a London-based urban experience design studio.

Priya started off the session by explaining that design principles describe the experience of core values of a product or a service. Design principles help in making decisions on your product. She referred to a great definition of design principles by Luke Wroblewski (see Fig. 1 below). The important part of Luke’s definition is that all decisions can be measured against design principles.

“Design is what you decide not to do” was one of the key points that Priya raised in this class. It’s all about doing less and simplifying things. She talked about Spotify and Google Glass as good examples in this respect:

Content first – Focus on the content, and remove any unnecessary user interface elements.
Get familiar – Even though there is a clear distinction between a “lean forward” mode (Spotify desktop app) and “lean back” mode (Spotify mobile app), there’s a unified design language which has been executed consistently, irrespective of the device that you access Spotify from.
Don’t get in the way – Google Glass is designed to be there when you need it and to be out of the way when you don’t. The goal is to offer engaging functionality that supplements the user’s life without taking away from it.
Keep it relevant – Deliver information at the right place and time for each Google Glass user.

Priya then talked about motion user interface design principles:

Personality – For example, the Pitchfork app has a magazine like feel. It’s about understanding what the content is and translating this into appropriate behaviours.
Responsive – Priya talked about the Clear app as being very responsive, explaining how this app gracefully expands or contracts.
Context – Motion should give context to the content on screen by detailing the physical state of those assets and the environment they reside in.
Emotive – This principle is all about evoking a positive emotional response. This kind of response can be triggered by wide range of user interface elements, for example smooth transition or a nice animation. Yelp‘s app is a good example in this regard.
Orientation – Motion should help ease the user through the experience. The “orientation” principle means that motion should establish the “physical space” of the app by the way objects come on and off the screen or into focus. The key is to get the flow of actions right, guiding the user on her journey and make sure she doesn’t feel lost or confused. Mobile apps like Yelp and Evernote do this pretty well in my opinion.
Restraint – Keep it simple! Similar to the abovementioned “orientation” principle, it’s important not to bombard the user wity too much animation or confuse them with too many interactions to choose from. This is one of the reasons why I’m so a big fan of single purpose apps; I like the simplicity that they offer and the level of design restraint that they tend to apply.

Main learning point: I learned a lot from Priya Prakash’s class on design principles, particularly with respect to motion user interface design principles. Design principles can provide valuable guidance for the design of any software product or service and should therefore not be taken lightly. Thanks to Priya for a great class!

Fig. 1 – Definition of design principles by Luke Wroblewski – Taken from: http://www.lukew.com/ff/entry.asp?854

“Design principles are the guiding light for any software application. They define and communicate the key characteristics of the product to a wide variety of stakeholders including clients, colleagues, and team members.”

“Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the the pieces of a project moving toward an integrated whole.”

Fig. 2 – What makes a good design principle? – Taken from Priya’s lecture at the Mobile Academy on 14 October ’14:

Specific enough to help make a choice
Focuses the team – avoid being broad
Measurable against user need or product/business goal

Related links for further learning:

App review: Do

October 5, 2014 marcabrahamLeave a comment

I guess we all know how frustrating it can be to have to sit in meetings that just feel like a waste of time or that could have been dealt with in 30 minutes (instead of 3 hours). I know that there are quite a few apps out there which help us to run more productive meetings, but I decided to focus on Do:

How did this app come to my attention? – I got an alert from Product Hunt about Tools for Product Managers, promising me a list of “the tools the pros use”. Do was only ranked 10th on this list, but I guess it was this comment from one of the Product Hunt voters, that intrigued me the most: “I was a Yammer PM. Do.com is the meetings platform I wished I had.” Especially given that it came from a guy who used to be at Yammer – who are all about collaboration within the enterprise – this comment made me want to find out more about the product.
My quick summary of the app (before using it) – Do helps you to have more productive meetings; I therefore expected a tool which helps its users to make their meetings as efficient as possible. The tool doesn’t yet seem to be available on iOS or Android, only on PC.
Getting started, what’s the sign-up process like? – I have to sign up to use Do. At present, Do only seems to support Google users; all non Google users will be notified as soon as they will be able to sign up (see Fig. 1 below). Once I’ve selected my Google account, I get presented with a permissions screen (see Fig. 2 below). I click “Accept” and my personal dashboard appears. All fairly straightforward.
How does the app explain itself in the first minute? – The default page of my dashboard shows a simple timeline with meetings on the relevant dates and times (see an example in Fig. 3 below). To be honest, I felt a bit underwhelmed at first , thinking “is this it!?”. However, the subsequent overlay which consisted of six ‘how to’ screens was quite useful, explaining in a simple but effective way how to best get started on Do (see Fig. 4 below).
How easy to use was the app? – Using the tool felt very intuitive and easy. The layout of the dashboard is clear and easy to understand. Adding a new meeting to the dashboard felt no different to doing the same thing in Google or Outlook (see Fig. 5 below).
How did I feel while exploring the app? – Like I mentioned above, exploring Do felt incredibly easy and intuitive. The signposting used in the tool is self-explanatory and the navigation options have been kept to a minimum. A quick click-through on an individual agenda item highlighted a key purpose of Do; the ability to create and share a meeting outline, making it easy to collaborate around meeting goals and agenda items (see Fig. 6 below).
Did the app deliver on my expectations? – Yes, it did. I felt a bit underwhelmed at first, expecting Do to provide more, ‘less obvious’ features. However, whilst playing with the application, I discovered features like “Invite” and “Takeaways”, which I believe are missing from most standard diary / meeting applications.
How long did I spend using the app? – A few days to start with, but I expect to be using it a lot more in the future!
How does this app compare to similar apps? – I had a quick look at MeetingHero which serves a similar customer proposition to Do. At a first glance, MeetingHero seems a bit less advanced and intuitive in comparison to Do. MeetingHero is, however, available as an app on iOS which means that the app can be used on the go.

Main learning point: Do is a straightforward and easy to use meeting app. I like its interface and its key features; the app makes collaborating around meetings very easy. It will be interesting to see how Do will perform in already crowded marketplace, with apps and systems that enable similar things. I’m now curious to see what the mobile version of the application will look like!

Fig. 1 – Screenshot of Do’s sign-up screen

Fig. 2 – Screenshot of Do’s permission screen

Screen Shot 2014-09-30 at 05.09.57

Fig. 3 – Screenshot of sample meeting in my meeting calendar in Do

Fig. 4 – Screenshot of one of the introductory ‘How to’ screens on Do

Fig. 5 – Screenshot of functionality in Do to create a meeting

Fig. 6 – The ability to share a meeting goal and agenda items

Twitch and its appeal for Google and Microsoft

June 1, 2014November 25, 2014 marcabraham1 Comment

The other day, I heard about the rumoured takeover of Twitch by Google for the handsome amount of $1 billion. I have to be honest; up until that point I had never heard about Twitch. Reason enough to look into Twitch and a possible ratio for Google willing to spend such a large amount of cash on this startup:

What is Twitch? – Twitch is a video streaming platform and a community for gamers. Geekwire describes Twitch as “the ESPN of the video game industry” and says Twitch is a leader in that space. Twitch has over 45 million monthly users and about 1 million members who upload videos each month. In a relatively short space of time (Twitch was launched in June 2011), Twitch has successfully created an online streaming platform for video games.
Who use Twitch? – I’m not an avid video gamer myself, but browsing the Twitch website tells me that are in effect two main user roles, which are closely intertwined: game players and broadcasters. Clearly, you can be both and I’m sure that a lot of Twitch members fulfil both roles. One can play games on Twitch channels like Counter-Strike: Global Offensive or World of Tanks or one can create their own pages from which you can broadcast games. A great example of Twitch’s success in engaging its community around a game is TwitchPlaysPokemon which has had over 78,000 people playing a game that turns chat comments into controller inputs, parsing hundreds of thousands of ups, downs, and starts and translating them into in-game movements.
Why is Twitch such an interesting acquisition target? – Twitch is reported to have snubbed Microsoft’s takeover offer but is rumoured to have fallen for Google. This raises the question as to what makes Twitch such an interesting takeover target? I think that the answer can be split into two main factors. Firstly, scale. Twitch has a rapidly growing and very engaged user community who all share a passion for (video) gaming. Secondly, live broadcasting. Going back to the example of TwitchPlaysPokemon, Twitch streams games that get people excited and gets them participating in real-time. This simultaneous element is something that for instance YouTube is lacking. YouTube is great for on-demand video content, but (currently) less so for live event coverage or participation. The combination of both factors (as well as a very rich vein of user generated content and data) makes Twitch an extremely interesting target indeed.

Main learning point: Recently there have been some major takeover deals in the digital industry – think Instagram, WhatsApp and Beats – but the rumoured acquisition of Twitch by Google is interesting for a number of reasons. If I have to highlight one key reason, then synergy is the main aspect that makes this potential takeover sound like a very exciting one. How will Google potentially integrate YouTube and Twitch or at least find a way to combine both platforms? Will the acquisition of Twitch help YouTube in cracking the real-time broadcast element of its offering? Lets wait and see if the deal actually gets done in the first place, but if it does then I will definitely keep an eye out for any future developments involving Google, YouTube and Twitch.

Related links for further learning:

Facebook Graph – Can it really take on Google?

February 9, 2013 marcabrahamLeave a comment

With the amount of data that Facebook has on its users and their activities, I guess it came as no surprise when they recently launched Facebook Graph.

One of the first questions raised was whether Facebook is now looking to take on Google when it comes to search. In essence, Facebook Graph generates a variety of results (e.g. people, places, interests, etc.) all based on the social data available through your network on Facebook.

An obvious first comparison would be with Google+ and it triggered to me think a bit more about what Facebook Graph entails and how it compares to Google+:

Facebook uses the data it’s already got – I thought this post on Fast Company explains Facebook Graph pretty well: “Graph Search leverages Facebook’s social data to pinpoint any combination of people, places, photos and interests. It is designed to field queries such as “photos of my best friend and my mom” or “friends of friends who like my favorite band and live in Palo Alto” or “Indian restaurants in Palo Alto that friends from India like.” In essence, all Facebook Graph does is using the social data it already has. In contrast, the launch of Google+ signified a venture into a fairly new area for Google, with it having to build a new social platform almost from the ground up.
Facebook Graph has its (search) limitations – It was interesting that Facebook founder Mark Zuckerberg said that “We wouldn’t suggest people come and do web searches on Facebook, that’s not the intent” at the launch of Facebook Graph. Indeed, Graph is no Google when it comes to web search; searches on Graph are limited to data that are either public or visible to you. Also, as the aforementioned Fast Company article points out; if one of your friends has wrongly labelled a certain picture it’s just a case of tough luck with Facebook Graph.
Different algorithms – Whereas Google’s search algorithms are predominantly based on keywords and links, Facebook Graph takes into social data around “likes” and “check-ins”. Consequently, the search results that Graph returns are likely to be a lot more personalised and authentic than Google’s. As I mentioned under point 1. above, Facebook has an almost endless amount of social data at its disposal which Google will struggle to compete with. Unlike Google, Facebook Graph enables users to search by using combined phrases such as “My friends who like cycling and have recently been to France.”

Main learning point: the main question I asked myself after having done this brief comparison of Facebook Graph and Google (Plus) was: “is it really fair to compare the two?” Google has clearly established itself as a very reliable web search platform, whilst Facebook Graph is clearly concentrating on “social search”. Having said that, I can see Google+ eventually suffering from Facebook Graph, mostly due to Facebook’s head start when it comes to social data. Facebook Graph, however, is currently only available in beta and it might not hit the dizzying heights that Facebook has hit. Facebook users might not sign up to Zuckerberg’s grand ‘one stop shop’ vision and prefer to search through Google …