Sunday, 13 August 2017

Building an onboarding process for a green field product

Photo by Riku Lu on Unsplash
Onboarding is an important part of B2C and pure "pay to play" SaaS. With so many tools to use, why would any user put effort into getting up and running? With B2B SaaS platforms that include professional services to get up and running then this isn't important. The same impact comes through the service that accompanies the product.

I have been lucky to experience a great onboarding experience when evaluating product management software for work. The best by a country mile was ProdPad. This had two elements, the first was the trial and flow to get up and running. The second was the emails the accompanied it. My previous post discussed the efforts to rectify the previous mistake, in getting email engagement up and running pre-launch, and how we use email in the onboarding process.


So the first decision was how to to go from registering an account to getting to the profile page. Should we create a blank slate and allow the users to build it up? Or should we go to a wizard process to collect details and finish with at least a partially complete profile? Given that the vision was to guide people we went with the wizard approach. 

Kick starting the experience

Next how could we kick start the process? Data entry is usually dull and most people already have some kind of CV or job/education history profile. How could we use this? Well, the most requested import in the beta survey was from LinkedIn. Luckily LinkedIn have a PDF profile download that we could use for the initial version of the registration process. 

Because this is the first experience people are going to have of the app as a user we really wanted it to be the best it could be. So it was the first full user journey where we've created wire-frames. This has gone through a couple of iterations now and is taking shape. It's still a way off where I'd like it to end up, but given how little time we get to spend on it I'm happy with the framework we've built to go through the MVP process.

Lessons learned

The structural bits are relatively easy to get going. We know from the design what the profile will look like at the end. The next challenge is get the guidance and feedback for the content down, but for that we need to launch!

... which brings me onto the most important lesson from this phase. Delivering something now, when you probably won't have any users, is better than delivering "the perfect process" next year. When you probably still won't have any users but you could have built some up and got a year's worth of valuable feedback. 

Also a great way to learn about onboarding is to do a product evaluation and try a number of products solving the same problem and meeting the same need. This really brought home to me how different ProdPad was. It also was interesting to see how empty space affects this experience. One of the products I used had a very minimal design. This looked great when it contained data, but as a new user and no data I felt a bit lost. Almost randomly clicking to find what to do next.


Further reading

Sunday, 6 August 2017

Brand - what is it good for?

Brand is a large part of what people see and remember about products and services. Here I talk about the first couple of iterations of building a brand for Bashfully.


Initial logo





When starting out I created a logo in one evening from some clip art and an online tool. It was this rather fetching and bashful apple to the left in purple. This was used to give the twitter and git accounts some character. But it was always known that it was a placeholder logo.

This became more obvious when the first version of the landing page was created and it didn't really fit anywhere. As we have prepared the design for launch day we have solved both problems, A bit more effort into the design and what it says, plus bringing in the "brand" colours to the site design.

Second iteration

We have moved from the excellent responsive templates provided by html5up to a custom design using the Bulma framework. The html5up site was good as it allowed us to get a decent looking site up and running while we brushed down our rusty CSS skills, and concentrated on the functional side of the site and user research. Now we are getting form to fit the function and it feels the right time to spend more effort on the design and structure.

I have also put some more thought into the logo. We both liked the purple, so have settled on the exact shade. But given the vision I wanted to convey more the "singing the praises" angle. We also both liked strong letter logos like Facebook or Google. I also wanted a font where the B would look a bit like a person ... not sure if I've achieved that!

Another subtle nod is the colour purple, we are helping people channel their inner "purple squirrel" and tell their story.


Building a style guide

I have also started a style guide as we go along, I know what a pain this can be to create afterwards. Here I am using the Mockflow Styleguide app. This has made it dead easy to create. Although one hiccup I did have was in uploading a font file - make sure you don't have a full stop in the name!

It may not look too much at the moment, but as we add more icons and colours into the palate it's going to be really helpful in making sure we stay consistent. The other thing that is going in here are text guidelines as we develop the tone of voices and brand language.

Although I have been through whole brand development at work with the Harrison Agency and at a lower level with the 15below module names, it's not my main focus. So, it has been fun taking more of this on. Another thing that I;ve picked up is that red and green are good, vibrant colours for print work but in digital product you have to be careful. Red is usually used to signify destructive actions or failure. Green means success or creative actions. Likewise blue for info and orange and warnings. Not to say that you can't use them, just more care has to be taken.

My main advice for greenfield projects is, get something as a placeholder. Don't spend too much time on it until the last responsible moment.Then build the style guide as you go along. This bit can be tedious data entry, so do little and often! :-)

Further reading

Sunday, 30 July 2017

Using JTBD in a B2B setting

It's now about 4 years since I started to think that the "As a ..." user story format wasn't the best starting point for building long running products. One of the things that I found and liked was the jobs story format.

The situation


When collecting the data I didn't do proper JTBD interviews as such. But I did extract the info from pre-sales calls, product demos, and talking to users. Plus enriching the collected date with the known strategic goals 15below as motivation , i.e. reduce support overhead.

I have adapted it a bit and marked it up for our dev teams here. But here is an example for a password reset function. Main thing is that as a B2B supplier we have four distinct groups that could appear in the stories.

  • 15below (us as supplier) as an org, 
  • our clients,
  • their users, 
  • and the client's customers 
Here is a simple example for a password reset function




all the words in bold are entities that have a defined meaning in a glossary, so that we try and get common understanding. So in this example, the clients are senior managers and procurement folks who set "the requirements". The users are people at the same org who actually use the platform to perform "the work". a Person is a real human being that is a uses the system. In this particular story we don't have the client's customers. Who are travellers (we do travel software). These are the people who get the output of the work and take part in two way communication. That's to say they are the users of our public sites and services.

One thing I keep meaning to update is "User wants to log in". This should really be the job they want to do in the system, as no user really wants to log in to sites. But it's pretty generic and could be anyone of at least 4 distinct workflows. Think that the format needs an extension to show the different paths needing the same behaviour.

Tools and support


I'm not using any specific tools for this. I am concentrating more on the process of getting the information that I need. Once created the job stories get treated like a high-level epic. So they get stored in ProdPad on roadmap items. Then pushed into JIRA as epics before being broken down into the tasks to deliver the functionality. One aspect that has been important to me is seeing the non-functional requirements. Then and making sure that they are considered in the design. I've never felt comfortable with non-functional requirements being hidden away and treated separately.

Once the feature is delivered, I am then storing them in Confluence. This allows me to use the page history function to track the changes in:
  • capability, 
  • constraints (non-functional requirements) and 
  • the user needs. 
Although the basic job to be done doesn't tend to change, the context and approach does. Usually in our development though, what happens is that extra motivation lines get added. Mainly as we go through the post-launch "product discovery" phase.

B2B and B2B2C differences


A lot of the guides to using the jobs to be done approach are very biased towards and end consumer. As such they favour B2C environments. As you can see in a B2B, or even B2B2C setting!, I have had to make some slight adjustments. It's more about also helping your client build a business case. How much their customers' needs come in depends on the balance in customer experience vs cost in their business model. So when looking at the data collected, there is another step in linking the needs and pain points of the end customer to the business driver in the client's pain points.

However you use this tool, bear in mind that the story format isn't the most important thing. The aim is that you can share context and the goals of your (potential) users. Frameworks are for finding ways for talking about what's valuable.

Thursday, 27 July 2017

Getting email up and running for side projects

Photo by Songeunyoung on Unsplash
Rectifying my previous mistake - not building community by using email engagement - has proved to be a learning experience! Since our investment is minimal (and we have no real users yet!) the tools that we use all come with some constraint/trade-off. This next bit explain this is going to be slightly technical ...

With Heroku it has surfaced as putting in CNAME records in the root of the domain. With register.ly this then stops us adding any other root records, for example mail servers. Cloudfare has a service that will flatten CNAME records for you into A records so everything plays fits together. So a switch of nameservers and 48 hours later we had email in place.

The services that we have chosen for email are Zoho and MailerLite. Zoho has a Office365/GSuite vibe going on and includes a mail list server. This setup not only works for newsletters but also the transactional emails. So we get account welcome, platform updates, and follow up emails as well. As someone who has been creating workflow systems for nearly two decades I am impressed by their automation setup. The main problem has been restricting myself to a very simple MVP. Too tempting to build a baroque workflow straight away! So this gives us the tools to get a connection to users and the app, with community building. I hadn't considered email lists, but have now added that to the roadmap.

As this project is taking shape we are using more of the skills from our professional lives. For example, a lot of the code to integrate these services now lives in a GitLab kanban board. We are creating issues for specific bugs instead of general cards in Trello then pushing code changes to git. Not sure why this is. Could be the launch approaching has caused it to kick in? Or it's getting to grips with DNS has reawaken what it's like to work in an early stage company.

As we are getting ready to launch we have also added a system status page. UptimeRobot has a great system for doing this. It evens includes the obligatory Slack integration for alerting. This didn't use much technical skill, add a DNS record and it worked. It was funny how excited setting this up made me!

I did originally write a whole post on the onboarding process. This fell a little flat as it was missing a lesson or stand out experience. The aim is to have more to share on that next time.

Saturday, 8 July 2017

Building awareness of Bashfully

So to validate an idea you need to have people be aware of you. The first step in Introducing bashfully was a Twitter account. This provided someway of people finding out about project, promoting the survey, and getting to the landing page.

Publishing the survey was one of the first pieces that I had available to promote. It was also vital in starting to get some evidence for the problem that we were trying to solve and the audience.

The landing page was a very important piece in getting started. When this was created it gave us a way of sharing progress, to explain the concept in more detail. This then meant that when we directed people to the survey from the landing page we could get better feedback.

Another key feature on the landing page was a sharing button on registration, this gave people who were interested a way of generating some word of mouth interest. Around the same time a friend asked me a question about her website and I noticed some interesting meta tags. This took me on a journey learning about Twitter cards and the Facebook Open Graph template

So, after a bit of experimentation I came up with this for our landing page

<meta name="twitter:card" content="summary" /> 
<meta name="twitter:site" content="@bashfullyapp" /> 
<meta property="og:url" content="http://bashful.ly" /> 
<meta property="og:title" content="Do you want a better online resume?" /> 
<meta property="og:description" content="Tell the world about your achievements through storytelling on Bashful.ly!" /> 
<meta property="og:image" content="https://bashful.ly/images/hamster-background.jpg" />

Which when you copy a bashfully link to Twitter gives you this ...



As the functionality develops we will be exploring this further! I wasn't expecting to learn this kind of thing when we started this side project, but it certainly has given me an extra insight to social media for my day job.

Once the registration process, landing page and survey were all up and running I started sharing. First with HBX networking groups as they are part of the target demographic. Then on twitter, first just from the bashfully account, later from my personal twitter and LinkedIn accounts.

Another important factor was starting to write blog posts and share on personal social media to boost awareness. The blog that really got interest going was one about the technical infrastructure. This lead to a lot of interest from friends and acquaintances. I'm guessing because of their background and the subject matter made it seem more "real". The lesson here is to write a piece that will resonate with an audience, then promote it to them.

As I was doing this and collecting together research I realised a big mistake. I hadn't thought about emails sharing useful information to people who had registered. This would have served two aims, the first the reason people were interested in the product in the first place - information and guidance about creating profiles and selling their skills. The second, more selfish reason, was to create engagement. Make sure that they remembered us when we were ready for the public beta.

It's a bit late to do that now as we are making such good progress! But it will come in soon after we launch. One benefit of doing it this way is that we will have a working site people can use and more concrete news that we can share.

Coming next are the lessons learned in building the onboarding process...


Monday, 3 July 2017

Chromebook on the go after 3 months

Bit of an update on cloud working and the tools that I'd picked out to investigate over the past three months: Draw.io is a great alternative to Visio, although working in a Microsoft dev and productivity stack I'd still stick with Visio. It's missing some extra collaboration features that would give it the edge. Which brings me onto Mockflow. This is a great wire-framing tool. The collaborative element allowed for some "paired designing". Each with our own laptop to look things up while the other added elements that we'd agreed to.

Pixlr editor is a good replacement for what I need in an image editing tool. Haven't missed the desktop aspect. Similar experience with Caret, although I haven't needed a text editor that much. Office online is a bit frustrating as it loses what should be a key feature - consistency. All I want to do is put some bullet points in!! But it suffers from the same issues that ALL WYSIWY HTML tools I have ever used suffer from. It gets confused between where the formatting applies.

As a laptop I have no complaints with the Chromebook, it makes the hardware a commodity item. One that I don't have to worry about. The ability to mount Dropbox and OneDrive as file stores also negates vendor lock in. I can have multiple back ups and work where it is appropriate. iOS even comes with a Google Drive widget so I can email my mock-up files on the go!

Where it gets interesting is with Codeanywhere and Cloud9. I prefer Cloud9 as being a bit more user friendly and a tad more RAM in the free pricing tier. It took no time at all to get a virtual machine running Linux and install R and create a PDF containing a graph.

This does open up all kinds of possibilities. For hobbyists, you can try out a new stack without much knowledge about the setup or ops. Then if you don't like it get rid of and you don't have clutter on your system. Then have a clash of libraries the next time that you want to try something. It also provides the ability to get some experience while using similar technology to enterprise systems .

For startups you get access to enterprise style infrastructure, if not scale. One of the most surprising things for me as I've looked at a couple of side projects is just how easy it is. I'm sure that for $9/month you could host an email marketing system for an SME. It'd (optimistically ;) only take a few weeks of full time work to get it up and running.

For enterprises that last sentence may seem worrying. How can competitor analysis keep track of specialist companies? Especially if they can pop up within a month and steal your business? Well, by doing the same thing. Get your pioneers to experiment. No need to wait for ops to be available. No need to worry about too much in fact. Do the experiment. Learn the lessons. Then either bring the experience in house or do some knowledge transfer. Or migrate to your usual infrastructure and tech stack.

The other aspect is that with scale in customers, you also have an advantage in problem knowledge. One way to keep customers is to double down on understanding their problems. Then solve them. Also keep revisiting this, to keep actual problems at the forefront.


* my optimistic and purely hypothetical SME marketing tool:
  1. Get the sending side sorted with basic metrics recorded (this would be heavily manual driven process by the startup)
  2. Get some reporting based on metrics for performance of first send to users (first time you give access to system)
  3. Get some basic content management for next send
  4. Get billing in place ready for first invoice
  5. Then refine each aspect of above each time you sell it

Of course this is dependent on experience with the technology, free time, and understanding customer you could get each stage above down to about a week. It's also not going to be competing with Pure360 after a month, but it will do a job for someone.

Sunday, 25 June 2017

Building Bashfully - a brief background

The first guest post here on "Part of the Process" from Martyn Osborne as he explains the Infrastructure side of bashfully, a parallel concern to testing the vision.

Since we've recently publicly unveiled Bashfully, it seems prudent to run through the technology stack and why we chose it.  I’m hoping it may also at least partially explain why starting a side project was appealing to me!

Backend stack

Naturally, there were some elements I wanted to focus on when selecting the language:
  • Fun.  As it's a side project (in addition to a full-time development job), I wanted something interesting to play with in my free time.
  • Different.  During the day I spend most of my time in C#, F# and JavaScript in Windows-land.
  • Functional.  I love F# and the paradigm, so that was the direction I wanted to go.
  • Web sockets.  This project is a toy - and I wanted to play with them at some point (of course, when appropriate!)
  • Practical.  Yes, I wanted a toy.  I also wanted a project that will eventually materialise!

I had been keeping a close eye on Elixir for quite a while, and Bashfully seemed an excellent excuse to use it in anger!  Elixir also has an excellent web framework with Phoenix, and an exceptionally helpful community.

So far, Elixir genuinely makes me happy.  I personally think that’s high praise, and I may dive into more detail there in the future.

PostgreSQL suffices for persistence.  Elixir has good support with Ecto, it’s easy to run on my machine, and Heroku allows remote PSQL sessions.

Frontend stack

To be honest, I battled with the idea of making Bashfully an SPA for a while (and I have some expertise in that area).  However, I now believe that would have been overkill; especially at what is essentially a prototype phase.

Instead, we’re primarily using Phoenix to render pages on the server side with Vue sprinkled throughout where advantageous.  I’m not particularly attached to Vue yet, but it’s sufficient and I am eager to explore further.

Hosting
                                                        
On the hosting side of things, Heroku has been fantastic.  We’re using GitLab CI to build, test and immediately deploy Bashfully to our Heroku staging environment;  we can then promote that build to production with Heroku’s pipeline feature.  This was working well within an hour!

Even though this setup was primarily to make my own life easier, it also had the interesting effect of allowing Neil to easily make design, wording and content changes to the application (via GitLab’s excellent editing UI) and have them deploy to staging without any technical barriers.

Security

This bit is pretty important.  We have worked on a similar web application for a while and have learnt several lessons along the way; these lessons have been incorporated into Bashfully.

We decided from the very beginning to go passwordless and use third-party authentication providers (Google, Facebook, etc).  This was trivial to set up (we’re using Ueberauth) and means we don’t have to process or store credentials - very helpful in the age of data breaches!

Site-wide HTTPS has also been implemented courtesy of LetsEncrypt via Heroku.  

My advice

For anyone else attempting a side project (and with the intention of going live in a reasonable timeframe!), I would suggest:
  • Don’t pick any technologies too esoteric.  Make sure they’re fun, but also practical!
  • Do pick some technologies that you are familiar with.  Writing good quality idiomatic code when learning one technology is hard enough - don’t try it with too many.
  • Keep the infrastructure simple.  I toyed with the idea of building the infrastructure myself on AWS;  but not doing so let us concentrate on the mockups, journeys, and the application itself!
  • Define your vision early on.  Staying focused on building the right things is critical, and a vision helps (especially as a developer!).
  • Break the project up into smaller chunks.  Something like Trello is a great help.  I would argue that this is a critical skill for any developer and one that a side project can help with.

Thanks


If you made it this far - kudos!  I will probably be expanding on these topics in the future, so keep an eye on this blog!

To add to this, not only was I using the GitLab UI but I have created, merged and squashed feature branches. I have even wired up some page handlers unaided without knowing any Elixir or Phoneix!

Thursday, 22 June 2017

MEETUP: "A look into what every Product Manager forgets " at ProductTank Brighton

Three varied viewpoints and interesting talks at tonight's ProductTank, around what Product Managers usually forget. First up was Mark Rodgers sharing how they overlooked things in the first iteration of the new image search functionality at Brandwatch. I can completely relate the situation in my own work. That thing where when you see the product with real data and a real usage situation you suddenly notice something and think "how did I miss that?!", since it now seems so obvious. This made me feel a bit better that if someone, as experienced with Mark and with his team at Brandwatch, can make that mistake it's not surprising I do.

Next was Ben Sauer from ClearLeft. His talk was a more abstract look at companies culture. For example, how it is all around us but that we don't notice it. And consequently (or maybe because of?) we don't discuss it enough. He recommended a couple of books to read Creativity, inc  by Ed Catmull and 
Nonviolent Communication: A Language of Life by Marshall Rosenberg that I am looking forward to reading. Especially as he said the lessons of applying NVC to his life had improved his relationships. One particular piece of advice that stuck with me was to use comedians for change. That is if you are using videoed user feedback to convince "higher ups" that something is a bad idea, get someone funny. He put forward the suggestion that it helps if people can laugh at themselves when admitting a coursed of action was wrong.
The final talk was Tim Stamp from Rakuten talking about security and how this can damage business reputation when done badly. I know that I have thought about user permissions a step too late in the design process before. One piece of advice he gave was to get someone in with a security focus when discussing the user journeys so that they can suggest how attackers could abuse the system. A related point that Ben made in the panel Q&A after, was that we don't have discussions about security/usability tradeoff enough. So get security in at the user journey mapping should help that happen as well.

It was also very satisfying listen to Tim talk about passwords, and if possible avoiding them by using single sign-on. Exactly the approach, and for exactly the same reasons, why we have avoided them on my side project!

Sunday, 18 June 2017

Introducing bashfully

So in my last post on the "untitled side project" I said that I would elaborate more on the idea. When we started the project we had a strong idea of the kind of project that we wanted to do. And after settling in the area I started doing some reading around and thinking about who we could help. What change were we looking to make in the world? How were we looking to alter behaviour? (a litmus test for innovation) 

The project is called Bashfully. Partially a play on the concept of being bashful and shy about talking about your achievements. Partially because the name could be part of the domain in the .ly TLD ;-) This project is to provide an online resume to help people shine in ways that the current sites do not. To help them be proud of what they have achieved. Finally, to allow them to see their career development as a journey and set their own narrative.

The Trello card entitled "what are we hoping to learn?" says:


MVP is to test the hypothesis that there is a market for a resume site and network for people in a creative role or within 3-4 years out of university. These people are not currently served by either LinkedIn because the format is quite restrictive/unispiring or Facebook because it is too informal and basic. Although both sites offer good networking and the target demographic are already somewhat established in at least one of these.
As the first step to sense check this I created a survey and shared on social media. Around the same time, we created a landing page. This had two purposes, 

  1. to share awareness of the project, including the survey 
  2. to build up the functionality iteratively
The first part of this functionality was the registration of interest. This is the foundation of the user authentication that the full site will use. It allowed us to explore the different APIs that we wanted to use and actually integrate with them.

The initial results from the survey were great. One idea suggested was almost word for word how I would describe it - with the caveat we need to be careful of confirmation bias! Another respondent gave us an idea that was brilliant and we hadn't thought of. 

The output of looking at these survey results also helped firm up the vision from the initial hypothesis.This was a vital thing to get in place. Any project and especially product needs to have a clear sense of:
  1. Who you are helping?
  2. Why you are helping them?
  3. How will this help them? What is the positive outcome for them?
Without this, any sense of prioritisation or ROI calculations that you will hope to do are likely to be a mirage at worst. At best you'll have a useful proxy, but that can change without you noticing. This is as true for a 2 person side project as it is for any commercial organisation. Probably more since we are doing this for fun and not profit, and launching is part of the fun!

Thanks for reading. The next instalment is likely to be on crafting the user journeys and mockups to test with real people (aka "users").

Further reading


Friday, 16 June 2017

Is "addictive" app design ethical?

Many years ago I used to live with someone who commuted an hour longer than I did. This was way before smartphones, social media, or even cheap laptops. So I used to do the washing up as part of my evening ritual of winding down from work - luckily she was also as relaxed about leaving the washing up as I was.

Thinking back to this time the main method of communicating online was via forums around interests. So Eurogamer, Get Your Boot On, and North Stand Chat for example. Here the conversations are around topics. The nature of content on the sites is discoverable and predictable. I could easily see new information that I was interested in. I could also easily show someone else something interesting later.

Fast forward a decade with smartphones and pretty widespread internet connections I can get a notification ping up on my phone instantly alerting me that someone I know has posted something for the first time in a while. It will probably be a cup of coffee. Do I really need to be that connected?

Don't get me wrong, in my line of work at 15below creating alerts for people on the move, who need really timely information about their journey, can be the difference between missing or catching a flight. The ROI of the joy of making a flight you would otherwise have missed is hard to capture, but I'd certainly call it progress.

What I wonder about is the switch from the topic based forums I used to frequent, to people based "social networks" that are a virtual stream of consciousness. Sure they can be easily discoverable. They can put people in different countries who have never met in real friendships. However, they can also be unpredictable. Feeding that part of our lizard brain that feels rewards for novelty. 

The worst for this is LinkedIn. I almost feel like the second I see something I have to like it, read it or share it. Otherwise, I will never see that post again. This actually makes the experience stressful. If I see multiple items of interest when I open the app it's a race against time to complete them before I move on.

It's a similar story with Twitter or Facebook. Constantly refreshing or switching between searches to see what's "new". Sometimes I even fall into a zombie-like state, swiping and refreshing. When I stop I'm exhausted falling into a daze. This undoubtedly has an impact on real life relationships. With mental health. Is the disruptive nature of the curated timeline worth the ads it allows the platforms to push in our faces? Because social networks are becoming so interwoven into our lives that not being present there can be just as isolating.

My Sunday morning last weekend really brought it home to me. When I got up, instead of the usual coffee and social media routine, I did some housework. I unloaded the dishwasher. Washed up some fragile glasses. Put some washing on the line. When I had finished and sat down with my coffee, I felt much more awake. I was also more relaxed.

As product people do we have an ethical duty to consider the impact of our creations on people? I use the term "people" here deliberately rather than "users". This is probably an enabling term that allows us to distance our actions from the impact.

I will leave you with this thought from the Pope - and whether online or in real life keep your interactions meaningful.
Sorry for the rant. I know it's not overly original. But I feel it is important. We need to be more aware of the issues and avoid them.

Further reading


Friday, 9 June 2017

CONFERENCE: TTI Summer Forum 2017 – Getting to Grips with GDPR

This week I was at the Travel Technology Initiative's Summer Forum. The subject was the new EU (and UK!) data protection laws. These are due to come into force in May 2018. It's a large topic where the individual member state's laws and guidance are evolving.

There were three main points that I picked up from the presentations. First from Dai Davis, GDPR expert at Percy Crow Davis & Co. His lively presentation talked about how a large part of the change is in how rights communicated. Before this was by "fairness" through registration of usage with a central body. The shift is to transparency by informing individuals directly.

This means that the consumer mindset could then shift to match how legislation is framed. For example, with the repetition of many companies holding personally identifiable information now having to inform what they are collecting and how they are processing it. Currently, awareness isn't high and the compensation not high enough to make it worth pursuing.

The next salient point came from Steve Dobson, IT Security Director, ATCORE Technology. He talked about how the new regulations move more accountability to data processors. So as IT suppliers we need to care more about data controller behaviour as it can comprise us as data processors.

The final point I'd note was that consent is key. Additionally with the rights of subjects to knowing what data is held you need to check that the request is coming from the individual in question. Also that you have the consent from them. This can be an issue on travel bookings. For example, where multiple passengers could request data held on the same PNR.

As a Product Manager for an IT supplier in the travel industry I also picked up some product ideas, but those are for my backlog not my blog ;-)

Further Reading

Monday, 5 June 2017

BOOK REVIEW: Product Leadership By Richard Banfield, Martin Eriksson, Nate Walkingshaw

I've had this book on preview as each chapter came out and I've finally had a chance to read the full release version. So before it gets officially launch at MTPCon on June 13th here is my round-up...

Formats: Paperback, DAISY, ePub, Mobi, PDF

Where can I get it? From O'Reilly, Amazon or .... any good bookshop, although I think there are currently only 500 physical copies left world wide!
  
Who is it for? Anyone involved in a software product development team or a startup founder thinking about which roles to hire next. 

What's it about? Product management, product leadership, not just the overlap but also the differences. How to grow your career as you grow into product leadership and how to hire the role for senior management.

What's the book like? The book is divided into three sections:

  1. The Product Leader
  2. The Right Leader for the Right Time
  3. Working with Customers, Agencies, Partners, and External Stakeholders

The first section concentrates on the different areas of product management, the skills needed, artefacts and processes required, and what success looks like. It might be too "meta" for some, but I liked the way it applied treating the role as a product that needed managing. For some of the lessons of moving from practitioner to leader I wish I had this book a few years ago as I stopped coding being a tech lead on projects! But it was useful to relate my experience to how the book presented information, I felt this gave me a kick start to absorbing the later lessons. It really gives a good flavour of the many different hats that you need to wear as a PM and how that evolves as the role gets more senior.

The second section goes into more practical advice and anecdotes around the kind of leader needed for each stage of an organisation - from start-up to emerging organisation and finishing with enterprise organisations.  This is useful in being aware of which skills to develop as your organisation grows so that you aren't caught out by that growth.

The final section starts off with trust and value, before covering topics such as when to hire consultants. One bit of advice I found surprising was to hire for either short or long term engagements, so either give an injection of new skills/views or to implement a new strategy. Anything in-between is likely to lead to the partial implementation of any strategy. There is also a good discussion of the opportunity cost and value when looking at short-term vs long-term needs.


Further Reading


Monday, 1 May 2017

Challenges in travel technology - a holiday makers perspective

I love travelling, not because of going to new places - although that is great! - but because I enjoy the journey. Mainly because I'm a travel and systems thinking nerd. My latest holiday was a chance to look at airlines and airports in a different way. Scheduled flights to hubs for business are one thing, package holidays to small airports proved another thing entirely. In fact, comparing Gatwick airport to Heraklion it is a good example of this quote
The future is already here – it's just not evenly distributed. 
William Gibson
It got me thinking about two major challenges to objectives of the IATA fast travel program being the norm across the whole industry.


Culture


The first is customer culture. Self-service common use technology is still in its infancy. Previously there has been a consistent expectation for example of what travel means, and how desks work, this is now being replaced with different tech and varying security rules. For example, even a large hub like Amsrerdam can have its issues


So far every "self-service" experience I've had at an airport has been slightly different. The only constant factor are there being a number of staff on hand, who are there to tell you how to use it. 

There is also the difference in business vs leisure/package travellers. For example, what use are home printed bag tags if your holiday rep is picking bags up and checking them in. So, all you have to do is go to security gate (best case) or if you have children you need to tag push chairs etc

Business travellers are also likely to have more idea about the self-service capabilities of the airlines and airports that they use most often. So giving leisure or infrequent travellers awareness of the airport facilities to prepare them can only be a good thing. 

But still, the experience and expectations vary greatly between airports. For example, a smaller airport like Heraklion where not all the check-in counters even take the luggage, here you have to get the bag tag from a counter and then take to the x-ray machine. Here it is not a simple case of installing a few kiosks and some software, there is a much larger infrastructure and business process improvement project to consider. Which brings me onto the next challenge.

Technology


The second issue is with technology roll-out. I don't see a major engineering problem needing solving. Additionally the problem isn't consumers, after all most "industrial" tech stacks a behind the consumer experience from finance and insurance to health and travel. It isn't the airlines, who although they have legacy systems largely in place there are providers that can deliver modern communications. It's the airports. Or more specifically the spoke and small leisure destination airports. IATA acknowledge this in their risk assessment:

Business case: Airports may be reluctant to invest and implement such solutions as they face the dual challenges of differing customer requirements in terms of technology and process as well as the lack of a coherent proposition that reduces airline costs while at the same time maximises value for the airport. Global industry standards help to minimise the impact and are at the core of the Fast Travel solutions offered by the service providers and vendors.
IATA Fast travel strategy

Part of the problem is the aping of consumer technology, but always being behind, so user experience is not consistent with the expectations set. Consumer replacement cycles are within two years but enterprise IT roll-out projects still take that long to complete; so it stands to reason that they will always be behind the curve. 

Two trends that will help here are firstly modular systems using off the shelf components pushing the "specialised" part of the system into software. The second is BYOD, having dumb infrastructure that again pushes the business rules and experience into a place where it can be easily updated to keep pace with consumer expectations. I don't think iBeacons and apps are the answer just yet, but I do think that they show a glimpse of the future way of working. 



Airlines probably stand to gain the most here from reduced ground handing cost and the airports that are going to be the laggards are in poorer areas. So it seems bonkers to me that the question of "who owns the customer" is heard as a blocker to both parties working closer together. 

Isn't the better question "what provides the customer value?" - so do more of this - and "what detracts from that value?" - so do less of this if possible. I saw a great example of a creative answer to the second question at Disney World, where young children can be made to queue for an hour during busy periods. So, they have themed play areas, with buzzers to maintain queue position, in the busy rides. The children are not only kept entertained and also out of the blazing Florida sun. 

I'll sign off with a couple of questions ... What would a creative solution to this look like for say security queues? Or maybe how could airlines share more data with airports to benefit from reduced costs?

Building an onboarding process for a green field product

Photo by  Riku Lu  on  Unsplash Onboarding is an important part of B2C and pure "pay to play" SaaS. With so many tools to use,...