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

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.

Should we design better products for older people?

This week I've been having a bit of think about products for an older audience, prompted by this tweet by Tom Peters ("The red bull...