Sunday, 11 September 2016

On Herzog and technique

I am a big Werner Herzog fan. I love his movies. I love his interviews. He seems like the kind of person you would want at a dinner party. So I was intrigued when he appeared twice in my Twitter timeline this week. The first was a quote from an interview giving advice to young film makers

I think that this is also great advice for developers starting out in their careers. People's problems and the work they do doesn't change as much as the underlying technology. This is a pretty simplistic example but I started running in 2009 and my experience is pretty much the same:
  • I listen to upbeat music of my choosing
  • I get statistics recorded of my performance
  • I can share those statistics on Facebook or Twitter
To support that I am on the the fourth device with about 6 different operating system versions. Starting off with an iPod and Nike+ sensor, then an iPhone 3GS, 5S and now 6. But the data is still there, sure there are some gaps when I didn't have GPS. I could also have switched to an Android device or used the Nike+ Sports watch. The technology changes. How I use it changes, and requires me to adapt to deliver the same core experience.

Another example from my work life. The product I work on, at its most simplistic reduction, delivers messages based on industry specific business rules. The recipient of these emails won't have noticed much change in the past ten years. Under the hood of the product though there have been a lot of changes. From use of VB6 and COM to early versions of .NET to bus based messaging. There have been various shifts in technology and techniques used that have forced adaptation. Luckily I didn't personally invest to much time in become a COM expert back then! Even the knowledge of how to deal with VB6 DLLs and Classic ASP pages isn't a great deal of use now. What is useful is the domain knowledge around communicating to people. About the stages of getting data and processing it.

The second occurrence of Herzog on my timeline was some commentary by Grady Booch on a film review. The tweets are in three parts, starting with 


“Whenever a self-driving car makes a mistake, all the other cars know about it, including future unborn cars.” Sebastian, I respect your metaphor and your POV, but let’s sit down and talk about the pragmatics of legacy code.

and finishing up
Again this tells a story about adaptation. How its not just the code we write but the data it uses to teach itself that give the outcomes we want. The cars of the future will learn about the mistakes of today if we adapt the code and data from one technology to the next. This has been easier in the past where the code and data are separate. 

In a world where we use inputs to evolve the "code" running then we may need to treat AI more like employees. With one generation "training" the next, passing on the data in a way that it can become part of the new model. With human beings our mortality and imperfections in passing on knowledge helps prevent a build up of useless information .... well to a certain degree! With computers it looks likely to be obsolescence preventing the passing of useful information. So yes, even with AI it appears we need to focus on adaptation rather than a particular technology that will get dated.

Thursday, 8 September 2016

SimpliFlying Airline Marketing Innovation Lab - Aviation Festival Europe 2016



This week I spent half a day at the SimpliFlying Airline Marketing Innovation Lab. This kicked off the of the build-up to the Aviation Festival. There were a range of people from different airlines attending. Covering social media and marketing roles. I was part of the "disruption communications" rotation, so got to hear a range of approaches to the different scenarios. 

One thing that is striking about airlines is how open they are about most operational matters - just don't ask them to share commercial details like ancillary deals! But that's probably as how airlines deal with communications or customer service is closely aligned to their brand. Even if they use the same tool or know the techniques of another airline it may not make sense in their context. EasyJet is different from BA who are different again from Emirates. 

I wish I could share more from the day, but I'll leave with this. The customer service professionals at airlines aren't uncaring robots. They also do try and solves people's problems. But they can't always share details of what they are doing in public channels like Twitter. Although being human and following company policies, they sometimes do make mistakes, like United after they broke a guitar

Further Reading

Wednesday, 24 August 2016

On #TravelTech and industry verticals

Industry verticals can be big beasts. I work in "travel" or "travel tech", depending on how granular the segmentation gets. But this covers a range of people who have many different needs. It also covers many different levels of accessibility to the problem. 

This week I'll take a look at a variety of blog posts in "Travel tech". Written by those involved in solving different problems in the same vertical. The experience and accessibility to the problem area isn't evenly distributed. On the one hand, many people have experienced booking a holiday or catching a taxi. By comparison not as many have communicated to passengers following an airline schedule change.

Consumers making a travel booking 

I would like to contrast two different approaches here. The first is the the developer with access to the API calls. It is now possible for anyone to create booking apps with relative ease. I love the fact Arun's use case was "here is my budget, find me somewhere". This feels like how I research travel. But not the way that most sites have traditionally been organised. We have got used to reposing the question around the data and how computers search it. Compare this to how the developers of a Rome2Rio tackle the booking journey. As a multi-modal booking site, they have a lot more data at their disposal to test how effective UI changes are. Although it would be great to see more searches around budget and properties of the trip. Makes me wonder if this is an experiment that they have run. After all, it is possible that Arun Rajappa and I are the only people who like this kind of search!

The second class of people are designers and product people. Who as part of their lives encounter issues they would like to fix. For example Rudy Rosciglione interviewing at BlaBlaCar or frequent traveller Peter Smart who wanted better boarding passes. In this camp I love that SkyScanner took the feedback from Ash McCallum and then used it to inform their improvement. It was also great being part of the same online community that he is part of, as he appeared excited that they had picked up his ideas. The boarding pass example is interesting. Designers without domain knowledge, often want to leave out key pieces of information. They don't appear important but are part of the boarding pass specification.

Corporate Travel Booking

Another category under "travel" are those people who book travel on behalf of someone else. Like consumer sites you want something easy to use, but you have different drivers like policy compliance. Here the destination choices and selling the dream aren't as important.  But managing the booking as a whole is. Collaborative planning mentioned in the blog post is a great idea. Again feels like reflecting how humans would tackle the problem without an IT system in the way. Corporate travel isn't as glamorous as consumer bookings

Travel providers

The final group of users are those I deal with. The people working for the companies providing the travel. This has different challenges to the booking angle. Everyone has already picked where they want to go. When they want to go there and how much they're willing to pay. Now there are a variety of systems to help airlines, train operators and ferry companies deliver that service. This is an interesting area compared to those above as they are funneling down to one choice. After which you do not need the other bits of information. For the travel provider they narrow the search down to target groups of people to help. Here though the other people still need to given help. The system needs to support searching and track information in different ways. There are also fewer consumer systems that you can share conventions with, such as edit icons. This can be a blessing in being creative! but also means that you have conversations about which icon says "booking not processed due to simultaneous changes" :-)

Further reading



Sunday, 14 August 2016

On performance and environment

Hobbies are a great way to relax and unwind from work. They are also an excellent opportunity to practice some skills and learn about yourself.  Photography shows a clear visual representation of how practice with tools can improve output. Running I have found has taught me a couple of lessons about performance and motivation. Here are my top four

Goals are important 
An arbitrary goal, doesn't fit in
any plan but I feel good
Yes, even arbitrary goals. As long as they have a narrative that you can use as a guide. They provide a sense of progress and small achievements to celebrate. 



For example as an individual runner, it makes no real difference to my life running 10km just under an hour. Or a bit faster at 51 minutes. But the difference in the sense of pride and achievement in my progress was real. 


Your environment matters
Periodically I pause from running then have to restart. Sometimes this also involved a house move and I need to find a new route. On one of these occasions I picked out what appeared to be a nice loop of around 5km but it felt awful. It kicked off with a hill to get it out of the way followed by a flat section. The next day I did the route in reverse. Bingo! Much better. Faster time and I was much happier other the run. Small changes in your environment can make for better performance ... And more joy. If you are having difficulty getting the job done, and the order of tasks does not matter, then try mixing it up. Sometimes "the obvious" way isn't the one with the best flow.

Your environment matters part 2
Music can give you a massive boost. Since the 2012 Paralympics I have started my runs with Public Enemy's Harder Than You Think. It gets me psyched up. Now I've been using it for so long a Pavlovian response kicks in and when I hear it I expect to run. On a previous route I even timed the last 200m to coincide with the bass kicking in on Moloko's I Can't Help Myself. At work I do a similar thing and tailor the music to suit the mood I need. Something uplifting before a meeting, or something with a rhythmic beat for writing.

Habits can be good
The other thing about restarting running is that you get out of the habit of going. When starting again I look at one metric - it could number of runs a week, average pace or distance covered. It doesn't seem to matter you choose to start. As going out starts to form a habits, you can move the first metric then move the next one. Much like impact mapping.



Don't care too much what it looks like from the outside
Me looking stupid, but I don't care :-)
Bit of a random one. When starting out things will feel weird. You might not feel like you "look like a proper X", whether that's a runner or product manager. For example a couple of years ago I did the colour run. As part of the race pack we got a free headband with "colour runner" across it. At first I felt a bit of an idiot going out with this on. Then I realised that I didn't have single problem with being able to see. No more to wiping my eyes every 100m! Non-runners didn't see the benefit it gave me. This reminds me of when "agile" hit the office. All the sharpies and post-its, planning poker cards looked strange. Those that understood the theory knew that there was a reason for each. 



Further reading


Sunday, 7 August 2016

BOOK REVIEW: Jolt by Justin Jackson


The past week I have been getting through my backlog of books and reading Jolt by Justin Jackson. So without further ado, here is my first book review!

Formats: ePub, Mobi, PDF

Where can I get it? Directly from the author via https://justinjackson.ca/jolt/

Who is it for? As the site says it is
"A book for programmers, designers, freelancers, makers, and entrepreneurs."
What's it about? How to sell and connect with your market. This isn't a guide, or even a replacement, for traditional marketing. But ways of getting people interested in your new side project or start up. This is much more about authentic community building and engagement, the selling almost seems to be a byproduct.

What's the book like? Each chapter follows a similar style starting with an anecdote. Next is a description of the theory the anecdote displayed. Finally, the chapter finishes with some practical ideas. This takes the theory and presents it in ways that you can apply it for whatever you are working on

I like this for a couple of reasons. The first is that it matches how I learn. Experience prepares the ground for the theory. First piquing the interest of "why does that happen?". Or starting with theory. It gives the structure that allows you make sense of what you are experiencing. 

The second reason is that it makes the author Justin a real, living person. Rather than an expert who must be obeyed. The reader gets to see the experiences that shaped the lessons and advice given. I found this builds trust and authenticity over the course of the book. 

I also like that he has tweeted other lessons he learned during the book's production. Brilliant  form of promoting how useful the book is. this is the kind of material that you can expect, Chapter 10 on "swag" is like this tutorial on steroids. 

In short "I loved it!". It's an easy read. I can recommend this book for anyone seeking inspiration in how to look for opportunities and then make the most of them. You'll do this by exploring some fun ways to find value in your community. 

Monday, 1 August 2016

BCS PROMS-G Spring School 2015: Project startup. Is there an art to getting it right?

Once you have the results from the spike you are ready to start the project. That will develop the excellent feature or product from your roadmap. How the actual project then starts can have a massive effect on the results.

On that topic "Project startup. Is there an art to getting it right?" was subject in the BCS PROMS-G Spring School in 2015. One session I enjoyed was  Project Start-up - Acknowledging the Outside World. Here two members of the National Audit Office (NAO) shared observations from reviews of large projects.  Often problems in government projects are as a result of issues at the project start. They estimate that around 75% projects late/over budget. So, £300bn of tax payers money at risk (seems to be cycle where much better in election years before going up ;)

The NAO approach has been to pay more attention to major projects. Looking at value for money and delivering, rather than just cutting costs. Alison and Grace then talked about the report "initiating successful projects". This discussed the five factors that affect project delivery. (There is also an interesting paper on over optimism )

Performance management was one of the biggest issues found. Often that no performance management system. Second biggest was that people don't know what they want, which leads to scope creep. Third is uncertainty due to lack of stakeholder consultation. Finally, bit odd coming from an auditor was culture. Were they bidding low to win work? then not wanting to upset the apple cart etc

One NAO case study discussed in detail was the FiReControl project. On this project, there was no business case before starting work. During the planning, there was no critical path analysis. This lead to building's construction work finishing before IT systems contracts let. The relationships were also poor between team, stakeholders and contractors. So the infrastructure and IT aspects of the project were not coordinated!

In a nutshell planning for success involves:
  • Benefit articulation - Why is this project a good idea? what's the vision?
  • Relationships - How are the communications between stakeholders?
  • Organisational capability- Do you have the skills needed to deliver the project?
Grace and Alison then did an exercise using the Delivery Environment Complexity Analytic (DECA). This is a framework for risk analysis highlighting the points above. This covers 12 factors in the following three areas:
  1. Priority (vision)
  2. Feasibility (Realism)
  3. Delivery Capability (team)
This was a great exercise. We looked at a bridge project to see what we thought the potential pitfalls were. Even knowing little about the details we were able to explore areas for investigation. These were things like the experimental nature of the bridge materials. Or the expectation of usage and behaviours of commuters. The DECA link above includes a blank template and usage guide.

We then had a panel discussion and I've noted the key takeaways
  • Communication is key.
  • Decisions need to be taken by the appropriate people. So don't make proxy decisions in project team!
  • Need commitment from exec to enforce governance (and not allow workarounds or ignoring plans).
  • Lots of different "languages" used according to context. The BA had hard job in removing context to keep meanings for requirements.
  • How to deal with "dishonesty" in reports. This could be a form of delusion due to POV and context, e.g. Policy vs operational in civil service and once policy decided hard work all done. (This is a risk I've seen, implementation is often underestimated).
  • Interesting one from NAO. Fixed price contracts bad for startup. Any supplier who plays the game can make *any* scope change or requirements an oversight cost. Time & materials with cost/person/hours a month specified much easier to budget.
  • When changing people's behaviour via an IT project own it and agree that first. Don't leave the IT supplier to take the rap. You need to factor in and manage the business change.
  • Finally, there was a great perspective on new PM coming into to restart failed project. They are not "better" but coming in with fresh perspective and a focus on future. This can have a massive impact even if similar skills and experience.

Monday, 25 July 2016

MEETUP: "Product Management in Unusual Places" at ProductTank Brighton

Last week was an interesting edition of the ProductTank Brighton meetup hosted by Pure360. The topic was "Product Management in Unusual Places". Reading blogs and books it is easy to think that Product Management falls into two distinct groups of "B2C" and "B2B". Yet there are some more interesting cases lurking in there.

Faye Wakefield from Comic Relief started with a talk on "When everything MUST be alright on the night, how do you test, collect feedback and iterate?". Her situation is unusual as the focus for the year is pretty much on supporting seven hours of television once a year. Most of the donations come during this time. The key goal is to collect donations so the culture is risk averse in experimentation. So this is an extreme environment for risk appetite.


What was similar here was small user base interacting over time a large period of time. This is not suitable for doing A/B tests, or other experiments, to discover how to improve service. One way to overcome this is to use benchmarking and research from other similar organisations. Faye mentioned that she is lucky to have Children in Need, which has a similar model.

Glen Corbett was up next with "What does the PM for Rolls-Royce Wraith actually do?". In his case, he has a small user base so each unit matters. The users also have strong opinions and expectations from the product. A key skill for him seems to be the stakeholder management and saying "No". The strong brand around Rolls-Royce helps here. His background for how he got into Product Management was familiar to me. As well as the imposter syndrome he suffers. One of the things I love about ProductTank is getting to hear actual concerns and problems other people have. Rather than the perception that everyone has it sorted. Then feeling that what you are doing isn't that bad!


I guess that small user bases are common for a large slice of B2B products. Again it doesn't leave much room for large statistical analysis of experiments. the other factor is it doesn't allow feature development to be spread across the unit cost in any volume. So there isn't much room for waste. Good user research and validation then prioritisation is important!

Janna Bastow finished the talks with "PMing for the unique B2PM community." Having recently signed up with ProdPad it was interesting to hear more about the onboarding process. Particularly the thought about the thoughts behind the activity prompting email follow-up. A key takeaway was that "you are not your customer". Even when you are a Product Manager making a product for Product Managers to Product Manage. (I also learnt that Janna says the word "Product" a lot during her day ;). This is a key assumption to avoid for any development team. I think the standard "As a ... I want .. so that ..." story format allows too many assumptions/projections here. So I prefer the "jobs to be done" format to surface these. Often the user need differs from the bill payer's or even system supplier's. Think about password policies or billing systems.

Now I'm looking forward to the Summer Social to have more of a chance to chat with everyone!

Sunday, 17 July 2016

On documentation and audiences

In this post, I'd like to make a short plea for better product documentation.

One of the entry points to the Cronofy API documentation has an explicit link "for Product Managers". This link takes you to their use cases page. Over the past few years, I have looked at plenty of API documentation. From PDFs to the current trend of a GitHub repository and wiki. This was striking in how unusual it was. But if your product is an API then why should it be?

In the technology service industry should we go further? Should there also be a "for testers" link? This could be like the Cronofy Product Managers link. It could reuse existing information but highlight and target them for a specific audience. For example, take the developer sections about rate limits and validation. Then add testing tips about your API for integration testing.

Stripe has good developer documentation. Yet you have to scroll down a couple of pages of information before reaching the words "Not a developer?". Although one major plus point is that it does explain what the API does by then. This is often seen as a bonus. For example, the blog for Launch Any lists it as number 11 in 10 Questions Your API Documentation Must Answer.

 
The examples of good API documentation over at Documentor are clear. But they lack a certain humanity. I believe that documentation deserves the same kind of tailoring as marketing literature. That we write with empathy for the audience. Good marketing copy does this. It builds a bridge. It relates the product to the reader and their concerns. Shouldn't we use the same skills to inform? If we are already using them to persuade and sell.






Sunday, 10 July 2016

On spikes and learning

Photo by Sebastiaan ter Burg
So having a good roadmap with themes it is now important to get the work delivered somehow. Unless the developers have done something similar enough before. You need some way of discovering how to chunk up the work. What you call this doesn't really matter, but I have used the agile term "spike".  According to a comment in the Agile dictionary, this is a rock climbing term. A spike is driven into the rock face to help support the climbers. Although it does not get us closer to the top it allows us to go faster and have a safer climb. Likewise, a development spike doesn't produce the feature faster, but it provides a foundation to move forwards.

In a project kick-off meeting, I remarked about how successful the spike had been. A developer there joked that I should write a blog about it, so here it is... "challenge accepted". I have been reflecting on what I feel made the spike successful.

This particular spike for "feature X" was smooth and successful for two main reasons. The first is that we knew the need we were addressing and the problems associated with it. The second is that we had clarity of vision and common understanding.

To break down why we knew the need and problems, we had
  • Proactive user feedback and research to discover what might be missing.
  • Years of support and change requests for requirements driven by this need.
  • Coupled with years of support for the current feature in an operations mode.
As a base, we knew what customers thought they wanted, what they had asked for and the operational things that we had to avoid. This fed into the clarity of vision. Starting with some basic lo-fi screens we had a couple of meetings to explore our solution. This  high-level design got a common understanding of the required outcome. Which fed a set of properly designed wire-frames. Now we had the journeys and data mapped. The next step was to document our understanding, in the team, of the things we needed to learn.

The spike itself ran as expected and produced outputs for each of the scope questions. Although working software wasn't a requirement. Some proof of concept code explored these questions. The learning progressed with input from product, the project team, and operations. This is something that we all had a stake in getting right for long term success.

That was for current product and replacement of a feature that already existed. What about newer features? Pretty much the same. Yet for "feature Y" we needed an extra spike to do some of the learning about the problem. To be successful spikes need to be clear and focused. 

The "feature Y" spike was not as smooth. We encountered problems with our understanding of a third party API and we also found a bug in it. Perhaps that alone was a minor success! There wasn't as much clarity about what the eventual outcome would be. Although this became the number one thing that we learned from the spike. So for new or unfamiliar areas a spike is a useful way of investigating the user need and problems. This makes sense to me, for new things we need to explore and learn more. Once you have this framed it is possible to do another focused spike on the solution. Like you would for a feature extending the current product. Depending on the nature of the problem this may not be needed. You may be lucky and find that you already know enough about the solution.

I have found that in a lot of ways the least interesting property of spikes is the code. The language or tools used shouldn't matter. The key thing is "what did you learn about the problem?" or if you have an answer to that already "what did you learn about solving the problem?".

Sunday, 3 July 2016

On roadmaps and themes

The wrong kind of roadmap...
This post was inspired by a chance conversation from a developer, from another Brighton based software product firm. This occurred during The Lean Event. The conversation started during an audience participation section of Jared Spool's talk . I told him about trying to organise around themes and in exchange He told me about a lack of connection without that. This pleased me as it meant I was on the right track, but also reminded me not everyone has it sorted (even if you think they do from the outside). Unknown to me at the time I was sat at the table with Roman Pilcher! (more on him later)

In the past three years there have been three big influences on the way that I look at roadmaps. Well that and software development, they are (in chronological order):



  1. Gojko Adzic introduced me to Impact Mapping at one of the first Product Owner Survival Camps. First we learned about the importance of goals. Then being able to measure the impact of changes you make to meet them.
  2. On a more academic note I then took the Open University course Managing Technological Innovation. During this course I read the paper "Technology roadmapping—A planning framework for evolution and revolution" by Phaal et al (2004). In this paper they discuss the various roadmapping approaches. And then described how this works in different industries and organisation sizes. This was useful for looking at aligning technology and business disciplines. 
  3.  Finally on a project to refresh our product's user interface. I needed to prioritise and produce a roadmap for hundreds of features. This is when I found the template created by Roman Pilcher. This was useful for communicating what problem we were solving and why. 

Once you have all these elements then it is easier to create a narrative. First telling a story about the problems people have. Then how your product will evolve over time to solve those problems. 

Of course that is great, but one thing that you need to do is gain trust from your stakeholders. From the management, the team, and the customers. By delivering. After that you need to deliver again. And again. To start with don't worry about having too little in your releases. As long as it's what you said that you were going to focus on and it works. Even if it is basic functionality. Remember that you can improve this with user feedback and it helps avoid analysis paralysis. 

The themes are useful here for providing some kind of commitment in tackling a problem. Without having to be certain on the exact features or time scales. They allow some flexibility in the face of uncertainty of what you need to do. Additionally in what you might discover as you start user research before delivering.

I have found that this momentum and flow is the most important thing to get right. Without it you can have the most perfect ideas and  crafted user stories backed up with data, but it won't matter. Roadmaps only mean something if the items on them get delivered.

Think. Build. Revise. Repeat. 
 

Further Reading

Sources

Phaal, R., Farrukh, C.J. and Probert, D.R., 2004. Technology roadmapping—a planning framework for evolution and revolution. Technological forecasting and social change, 71(1), pp.5-26.

 


Tuesday, 7 June 2016

CONFERENCE: Travel Technology Initiative Summer Conference 2016 - Moneyfor nothing

How to explain revenue mangement to normal people...
This year's TTI summer conference was around the idea of "money for nothing" - that is doing effective revenue management to get more profit without any extra product or inventory. Like most of the professions in and around travel, it should come as no surprise that data analytics and supporting business decisions effectively seemed to be the main theme of the morning. 

There were three speakers covering various aspects. Deniz Dorbek from
Wyndham Hotel Group started by talking about "Total revenue management" from a hotel point of view. This included exploiting spa, sports, food and beverage, meetings as well as room rates. A key point in her summary was around people in revenue management communicating and working closely with the marketing and online analytics teams to ensure success. 

Dimitrios Hiotis from Simon-Kucher and Partners is from a tour operator background and introduced tools at TUI, which he has then built on this experience working in a management consultancy. So he talked about the different strategies that you can apply depending on the needs of the organisation - dynamic pricing isn't always needed or desirable! - and the data available for different levels of sophistication. Again he made a point that the tool you use and complexity needs to match the revenue management culture and capability. 

Finally Neil Corr from IDeaS discussed the tool suppliers side, which was informed from having been a hotel chain revenue manager. He reinforced the points that Dimitrios made about the evolution of strategy, but also explicitly said the other aspects impacted P&L account might need to be looked at first. For example might get more benefit looking at the cost of acquisition through automated channels. 

In the panel discussion I particularly liked Dimitrios' point that as you replace manual processes, with sophisticated tools, you lose the experience and intuition of what is a "good price" in the market, i.e. How the market perceives the value of he product. It's this point that I think Peter Dennis, TTI chairman, then summed up with a fashion based analogy - It's not always about price but perceived value at point of the purchase, for example when buying a shirt, a nice experience in the shop might sway me from going down road where a comparable shirt is cheaper.

On the conference side, it is nice having a lightening half day conference almost on your door step - even though it does mean playing the Southern Rail lottery to get up there!

Monday, 30 May 2016

CONFERENCE: The Lean Event, Brighton and Phocuswright Europe, Dublin 2016

I have been struggling to write a summary of The Lean Event and Phocuswright Europe as they both packed in so much content, I have so many notes to read through! Taking the two together it's clear to me that they are natural complements. Indeed Umesh Pandya's talk on "Learing to build wayfindr: independant travel for blind people" would not have been out of place at Phocuswright, just as Gary Morrison's afternoon keynote on Expedia Worldwide could have been a Lean Event session on lean in the enterprise. So i'll pick a couple of sessions from each to talk about.

From The Lean Event 

There were so many good sessions over the two days, but I'll briefly talk about Jared Spool's keynote on "Building a winning UX strategy" for this insight on Innovation alone - innovation is the space between current experience and aspirational experience. The simplicity of looking at innovation as gap between frustration and aspiration/delight was quite surprising.

Jared also put forward the idea that roadmaps should focus on when we are going tackle customer problems not the technological solutions. He showed in using a journey map to show areas of frustration you can then target these areas and get them into the delightful zone.

I also chose this session as Jared also had a few examples from travel and airlines in America, so was of particular interest to me. There are so many systems and processes involved in taking a simple journey, especially one that has been disrupted, that the service design needs to consider the user expereince as a whole.

As an added bonus The Lean Event had a table where you could write yourself some takeaway comments as a reminder. They then posted these 3 weeks later, as it turns out that was a good time after the conference to be reminded! Recent enough that you can remember what it means, but long enough back in your day job that you might need a nudge.




Phocuswright Europe

I can't remember who said them but my two favourite quotes from panel sessions at Phocuswright were "is this a startup or a feature?" and "OTAs are tech companies" (Similarily "Ryanair is a platform" and "JetBlue is a customer service company that just happens to fly planes."). There is a strong relationship between these quotes although they cam efrom different panels. If your startup is just a feature OTAs should have, then they will replicate it if they can as this is their core business. I have picked two pitched to try and  illustrate this.


Elevator pitch - Packaging golf tours dynamically - this solves the problem of time constraints and hassle for consumer and as a distribution platform for businesses. Using ther widget means everyone can become a golf tour operator - without human intervention or industry knowledge, so can concentrate on their core business. 

This feels like it fails the feature vs startup test. The core business of OTAs is literally a superset of this feature, with this being just one "personalisation". The OTAs will have an advantage in the long run with greater reach, development resources and benefits of scale. Remember "OTAs are tech companies".


In a nutshell, the product scans through e-commerce sites and finds broken booking journeys to see where the problems with conversions could lurk. It scans pages to collect analytics info, rather than rely on tags in the link. Then compares which tags are there/missing/misconfigured. This runs as a SaaS platform to do the testing with no code to run on site. 

What I liked about this pitch was that the CEO has brought her experience from being a marketing manager, and the pain of the kind of reports that she had available, then she has created a product to fill the gap. My opinion is that this is not quite the core business of the current providers and a complimentary product, so more than just a feature.  this is even a product and service that a tracking provider or a large industry client like an OTA could use.

EDIT: Talking of features dressed up as products, after Phocuswright I became aware of an EU funded research project called EuTravel.This aims to a create multi-modal travel planning tool that seems just like Rome2Rio. After a further look at the project site I can see some science in there... however, mostly it appears to be subsidising competitors feature development. They could have worked with existing providers to collect data on usage and social change, if that's what they need, and I would've thought that this might be more cost effective. (As a bonus they could also have seen how different approaches of these partners changed things)

Further Reading

Friday, 27 May 2016

On AI and hype

Machine Learning Miller by
When I wrote about AI and the Future last year I was reasonably excited, as an Artificial Intelligence (AI) graduate, of the possibilities and jealous of those beginning their careers in AI. Since now they have the luxury of extreme computer power and storage, 3D printing and the other abundant pieces of technology needed to create the future bounded only by our imaginations!

The past couple of months though and I am noticing a bit of a trend in conference presentations (and tweets coming out of conferences) that seem to have moved a lot of the hope and hype around big data onto AI. Or more specifically machine learning. I am not going to single out any specific examples, but I feel this covers two basic areas:
  1. I don't need to know about my data or structure it to get useful information and 
  2. I won't need to configure things. because machine learning.

(Lack of) Data structure

I am not sure what is driving this need but I guess it has something to do with the falling price of storage and the rise of world wide data collection via the web. So lots of business now have lots of data sitting there. There is also hype about the businesses that do data analytics well - e.g. Amazon or Uber - that leads people to think "They make money from their data. I have data. I should be able to make money out of it".There are also lots of blog posts and talks about this tool or that (e.g. Hadoop or Map Reduce) has enabled the data analytics, which usually gloss over the basics like linear regression because everyone does that...right? 

In the Computerworld article Machine learning: Demystifying linear regression and feature selection they make this very good point
Much of the art in data science is understanding the problem domain well enough to build up a clean set of features that are likely related to what you want to model.
 and show how using training data that has been modelled with clean features outperforms using all the data without any domain insight. So yes, machine learning probably can be useful just be prepared to understand the data and be able to run your own regression analysis on any training sets needed.

Configuring things

Again, the hype seems to have come from wanting to copy successful market leaders and I can almost hear people thinking "Netflix adapt the recommendations without configuring it, can I configure my users menu structure? (or whatever)". Adapting to changing usage or conditions that your software operates in is a perfectly reasonable desire. But here it's worth asking how much "adaptability" to we really require? and how much of the conditions of this can I realistically foresee? For example adaptive polling of mailboxes may not require a vast neural net to see traffic cycles and usage behaviour to tweak the likely poll time. We might just be able to write much less code that has enough adaptability based on what it found last time and a simple heuristic.

Final Thought


So please, do explore the potential that machine learning has to offer but don't expect it to be a silver bullet or replace understanding your domain. I think that AI surrounds us to much now for another AI winter to set in, but too much hype isn't good for any tool or approach.



Monday, 9 May 2016

On Twitter and lists


Being into product development I am unsurprisingly fasinated by features and how other product people approach and solve problems. One particular feature that intrigues me is Twitter lists.  It is a simple feature with one configuration option - private or public - and one setting to either add people or remove them from the list. There are no big built in workflows or obvious big assumptions (at least to me) of how Twitter are forcing intending you to use their list. One of the things that I love about this is that it allows you to project your needs onto the feature and use it to solve your problem.

So being interested in finding out more about this - and wanting to test out Twitter polls! - I did a quick survey to see who else uses lists

Now it's not very scientific and the results were hardly overhwelming, but it did reflect a straw poll that I did in real life. Not much interest, but if someone was interested then they not only used their own lists but subscribed to other people's as well. Looking around I saw some interesting policies to get engagement based on following behaviour, e.g. This blog by Edward Nevraumont, so I wondered how lists could be used in a similar way. I have slowly developed a usage of lists to help me at conferences and it breaks down into three phases:

  1. Phase 1 - pre-conference

    As the conference organisers start to tweet including speakers twitter handles I create a public list for that event and add any accounts to it (including the organisers).
  2. Phase 2 - during the conference

    This is especially useful for multi-day congferences where I follow the conference hashtag for at least the morning session of day 1. Adding new accounts that I see pop up either on the hashtag or retweeted with the hashtag. This means that I am ready for day 2 to see what the other attendees or speakers are discussing and catch comments that may not have the #hashtag included (or a slight typo in the #hastag! ;-)
  3. Phase 3 - post-conference

    I now have a tailored list of people who are pre-qualified as interested enough in a topic to not only attend a conference but tweet interesting snippets on that topic. Even if I follow the people on this list separately it can be useful to quickly dip into likely conversation areas.
I have tried this a couple of times now with some conferences easier than others, for example The Lean Event (Brighton 2016) had mainly individuals attending who were active on Twitter is different from a trade show like Phocuswright Europe (10-12 May 2016) where my list is taking shape and which has more corporate accounts tweeting.

My lists are usually fairly plainly named in terms of intentions, just the event name. But I have seen some which are more of an invitation, for example I was recently added to this list inviting me to a face-to-face meeting at MTPCon ... unfortunately I wasn't there and only retweeted someone who was. This is where you need to be careful. Usually in my usage that's OK as we are interested in topics of interest rather than physical presence.

That's how one way that you can use lists, how do you use them?