Saturday, 7 October 2017

First mistakes and successes in the Bashfully MVP process

Since writing about Public beta and starting the MVP process I have gained more insights about our Bashfully launch. These are around what we have got right vs wrong.

Successes

  • Having a pre-release landing page
  • Having a baseline twitter campaign 
  • Using the above to get a baseline conversion ratio

The Twitter campaign had a segment list, budget, and set of content we could re-run. This allowed us to see that the Twitter engagements this time weren't being matched with similar conversion rates.

Exactly what we got wrong is what are trying to prove. But one thing is that we inadvertently changed a variable on the landing page.



This took the logo away from the landing page, moving it to a reusable sign in screen. This also made the registration button a generic button as below


Another theory is that the copy around the registration button made a difference. Luckily this is easier to do a simple A/B test around. So we'll tackle that first!

Whatever the cause another thing we did right was "releasing" early. First by having the equivalent of a download page to gauge interest in the idea. The second was then release a functioning version of the profile. This had about a third of the intended features. The main aim here was to gauge interest and to get feedback on the remaining features.


Overall, I'm please with the progress so far. Trying to adopt an experimentation and data-informed mindset is paying off already. We are able to treat any solutions to problems we find as hypothesis and test them. In the next phase we are also going to step up some qualitative user research.

Further reading


Monday, 2 October 2017

Public beta and starting the MVP process

So deciding to "go live" shouldn't be a difficult decision ... in fact getting people interested enough to use an early stage project is hard enough!

This is the latest instalment talking about going through the MVP process with Bashfully - my side project that hosts online profiles.

Once we did though we got to see some real behaviour. So far this has lead to us:

  1. Cutting two stages from the on-boarding process
  2. Improving the layout and language in on-boarding
  3. Adding a page describing the profiles in Bashfully
  4. Made the "Call to actions" more prominent on the home page
  5. Prioritised some mobile layout fixes after seeing higher than expected mobile usage
Using FullStory has been invaluable here. Being able to play back and share session, to see what people actually do across all users was so helpful. With our initial batch of beta testers (thanks Shaun, Chris and Ed!) we were able to ask what was going on, then check the video. We could then look for the same behaviour in the all the visitors.

Having tweaked and tested with real life testers, we then started sharing to a wider audience. First a mail campaign to the people who had pre-registered. Next creating a profile on BetaList to get a wider range of testers. This has a month's waiting list. So, to generate more interest we have tried a limited Twitter ad campaign.

We have also got into a rhythm of smaller updates to improve the functionality and usefulness of the site. Two big features we are looking at for the next stage, based on feedback are:
  1. GitHub integration
  2. Tailoring profiles and sharing specific versions of them
The first one really fits in with our vision to tell a story and link experiences in one place. With Open Source Software, developer and designers experience is a lot more transparent. We can tap into that, and use authentication from GitHub so we aren't adding to the number of passwords people have to remember!

The second was a requested feature before we even launched the beta. It makes sense, and is one of LinkedIn's weaknesses. We are really giving people the control of their story and how they share it. The ability to remove experiences that aren't as relevant and highlight those that are.

Further reading

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...


First mistakes and successes in the Bashfully MVP process

Since writing about Public beta and starting the MVP process I have gained more insights about our Bashfully launch. These are around what...