Sunday, 7 October 2018

Adventures with flow and transparency

Photo by Sasha • Stories on Unsplash
This is a follow up to my post on roadmaps and themes. I wanted to talk about experience in a B2B context with a platform product and SaaS-style model a bit more. Most articles out there tend to be from B2C or app products.

So about the time I wrote about theme based roadmaps, I was using a combination of spreadsheets, Trello, and JIRA ... all OK for their intended purpose, but all have limitations around use and structure for product people. 

Limitations that possibly are blockers in increasing flow and transparency in the product development process. So, why are flow and transparency important? I think this tweet by John Cutler sums it up



The flow aspect allows feedback and course alteration as new info is uncovered. The transparency aspect allows those that can input be part of the environment that you are creating to make better decisions.


So what do I mean by "flow"

To me it means having a regular and consistent progression of work through to delivery. It means not working towards an arbitrary release date. You have a light enough touch process to deploy through to production without much overhead. This implies having skill and discipline across the team in chunking up issues, to a minimal size, to flow through the system. For me, this was a natural transition from larger platform pieces tied to a theme. Then switching to unlocking the capability that they made available with smaller experiments.

It also means that you need a good understanding of what you are aiming for, to guide the smaller pieces of work and not get lost. To do this I needed a good picture of our options and feedback. Using a combination of spreadsheets, Trello, and JIRA was making this difficult.

Building foundations

The first step was to get ideas in one place, with customer feedback logged in same place to link to the ideas and build up picture of the need - with ability to  share with the team!

This become the place to start to flesh out ideas with high-level problem and value of solution if delivered, much easier to connect the dots. There was also an added benefit - the designs, user stories, and specs can all be held in one place prior to pushing to development management tool, e,g. JIRA, and results of spikes can form part of the idea.

Also now the data is more explicitly structured I can report on it - and daily/weekly emails can help communicate team activity

What happened next

Once all the activity was in one place, organised to try and explain what was going on and available to query on-demand. I learned three lessons:

First, people naturally want to help, but they won't be aiming for your goals or fully aware of your job role. I.e. they won't be doing your work for you ... so, you need to understand what drives them and where common work can help. Then use that for mutual benefit. One barrier is using a different system, so auto updates between systems, or simple logging of interactions, can ease collaboration. 

Secondly, flow has benefits is lack of management overhead needed in coordination, but unexpected events can through it off. E.g. a backlog in process can have a knock on effect that over time causes greater coordination to get momentum back. So, keep an eye on your delivery metrics. Not as targets, as they'll then become vanity metrics, but to track the health of the system. Dashboards that show trends are great for these.

Finally transparency is important for trust, but ensure that your audience understand what you are communicating and why. Be careful of inadvertently over-promising. One area of misunderstanding that can arise here is the different between a roadmap and a release plan.

Thursday, 23 August 2018

Returning to code, worth it for a Product Manager?

The past couple of weeks have given me opportunities to reflect on what I like about my job and previous experience. Partly because we are expanding the team at 15below, partly from doing a bit of coding. I have written a bit about becoming "post-technical" in the past, but now is the first time I have done much code in years.

The thing that I enjoy most is solving problems and helping people. Throughout my career solving business problems to help create positive outcomes has always been fulfilling. Now I get to help do that, then go back and refine the solutions. You don't always get to do that as a developer or in a project focused role.

Side project

Code wot I wrote
The first bit of coding is on my side project. Martyn has created a great architecture and I contributed the project import from LinkedIn (almost) all by myself. It feels to brilliant to code on a side project - you get a sense of achievement from seeing an idea come to life. It also provides a way to express ideas and a method of  collaboration. It's easier sometime to do some rough code and then hand over to a proper developer to complete. It also helps that Elixir is a nice language to use, and reminds me of Prolog.


Work

The second bit of coding recently has been creating a report for work. Slightly different motivation here. I needed some information to share and the developer resource to surface it was better used elsewhere. I had just enough skill to self-serve the report creation and I was still exploring what was interesting and tweaking how the data was tagged. So, it was much simpler for me to prototype what I needed. Once this has stabilised then I expect to handover to get integrated fully into our MIS reporting.

It has been fun using the RStudio environment, again with a nod to previous experience this time Matlab, although the language is different. I have an environment in an AWS instance that I can access via the browser on my Chromebook, and an install on my Windows laptop.


Should Product Mangers code?

At the same time all this was going on, a blog post answering the question "Should product managers know how to code?" popped up. I must admit, my heart did sink a little to see what that might contain. However, I was pleasantly surprised. In particular the tip it gives about learning some CSS and exploring  ‘Inspect Element’  to tweak pages and see how changes will look. Also learning what happens where in your application is a good idea. The best people I know that work in non-technical roles in software understand this.

So, although it's fun I don't think Product Managers need to code. It can be useful in understanding. Or self-serving for quickly prototyping ideas.

Sunday, 5 August 2018

Further adventures in SEO land: Organic search for side projects and startups

This is part of a series about my side project Bashfully, which aims to give graduates and other new entrants to careers a seasoned professional level way of expressing themselves through the super power of story telling. Following the core principles of being discoverable, personalised and guiding in approach.

I have already written about Venturing into the world of SEO where I setup the infrastructure on the site, like metadata and adding a sitemap. Then a little later When SEO meets the MVP process on Bashfully, where I revisited how search results appear and what I hoped for Bashfully.


Photo by Annie Spratt on Unsplash
This has been the hardest part of the project so far. As much as you can setup the structure and hint to search engines, if people aren't finding your site organically then they're unlikely to find it. So, how to get organic searches?


Taking a look in the search consoles the closest searches that appeared were “Bashful github” and "flickr integrations". Which got me thinking, how could our content be better for searching?


One of the things that isn't appearing in searches were comparison to "competitor" or complementary products. So I set about creating some pages to compare Bashfully to competitors. How to pick competitors? The first one had to be LinkedIn as the main player in this space, the second was GitHub with it's place as the "developers resume". The final spot to test out this idea came from doing my own searches for the kind of terms that we wanted Bashfully to appear under .... and the winner was VisualCV.


When writing the comparisons I set myself a couple of rule, first Be positive in introducing competitor. They are popular for a reason. Often not the same as Bashfully’s purpose. They also provide value to someone. The second was actually highlight the features that we liked and wanted ... Ok, maybe not all the features, but the ones we won't reasonably do this year.

As another stream to getting organic search we are doing some work to join and support the open source resume creation community. This will probably be the subject of another post, so won't go into it too much here.


Final step was to update site map, resubmit to Google and Bing to try to get crawled. Next monitor to see if it worked! Then tweak and improve the content.


Further reading

Tuesday, 31 July 2018

Creating a ProdPad progress report in R

Photo by rawpixel on Unsplash
My journey with writing new R scripts had taken a bit of break recently. It started with exploring Text-mining. Then creating my library of reports for Product Management. Although R takes a bit of getting used to, it is like Excel x100 once you do. It is great for repeatable analysis and report generation. Saving a lot of the hassle of the export, format, and save cycle that I was going through.


The problem

When I needed a new report though I took the chance to expand my skills. I wanted an automated report that showed progress in the product process. This was to show the pipeline to meet strategic goals in the product ideas worked on. This should be in a suitable format to share with senior management. An be understandable especially to those outside the Product team.


The solution

I had been manually noting figures from the ProdPad UI when I remembered that there was an API. I took a look and it is a nice RESTful API with a JSON payload, so easy to integrate with. Checking GitHub and there were a couple of projects for ProdPad, but none doing this kind of reporting. A quick google of "json r" later and I had found and installed a JSON deserialisation package (jsonlite). This created my R objects as from the API call.

I could then pull in the ideas, make a secondary call to get the workflow status and any tags that were applied to the idea. I choose to pick three tags to highlight and create variables for which stream of work each idea applied to. These each then matched to a goal from the strategic plan.

Next I added it to my "R for Product Management" project on GitHub. This was along with some explanation to get started for other users.



Expanding insight

Looking down the lsit of APIs available I then saw feedback - and it was in a similar format to the Twitter feed in the Text-mining example - so I created a word cloud on the past quarter's feedback. This should highlight trends in what people are asking for.

To dig a bit further I then used the topic modelling library. This allows you to find word associations with words from the road map. To try and reveal any insights that might have missed by reading them individually.

This is a very early proof of concept, and likely to change a lot with use and feedback from the team. But is part of my long term plan to be more data-informed, where possible.



Lesson 1: using function files

For the first time I extract my functions into a separate file. My former dev reflexes started kicking in. This meant that my main script process and formatting the ideas and feedback was short and easy to read. It also allowed the work to form part of a dplyr workflow, with standard R functions. I haven't put any tests around it yet, probably need to learn about mocks in testthat.


Lesson 2: knitr and kable

This was also the first time I had many raw data tables that I wanted to display in my Word doc. The plain text output is OK for me exploring in the IDE, but not great for sharing with other stakeholders. Kable doesn't have many options, but as a quick way to look like a Word style table it is perfect.

I did have a little bit of an issue here with two chunks of code producing table with a single line of text in the middle. For some reason it merged both tables and inserted the text into a row, words split across the columns. A few blank lines at the end of the R chunks and around the text seemed to fix that.



I hope that someone out there finds some value in my R scripts. Please feel free to fork and send me pull requests with any improvements! I am also always happy to talk to data-informed members of the Product Management community who might be interested in using R.


Further reading

Sunday, 1 July 2018

Making Bashfully less opinionated as we understand impact of complexity

This is part of a series about my side project Bashfully, which aims to give graduates and other new entrants to careers a seasoned professional level way of expressing themselves through the super power of story telling. Following the core principles of being discoverable, personalised and guiding in approach.


Photo by Nathaniel Shuman on Unsplash

New short term goal

One of the bigger things to happen to the project in the past month is creating a new short term goal to 
“make it as easy as possible to get resume info in and a PDF out”.

This came from engaging with a potential user on Twitter that really bought this use case out as a good hook. As a follow up to that we also got four new users organically. Finding our product/market fit has been very heavily influenced by a) how we show the complexity of the product and b) how opinionated we make the process of using it.

Succeeding in this short term goal then opens up a path to some more long term aims, which require a larger and more connected user base. So, this wasn't chosen in isolation as a quick fix. It's also about sustainability and thinking about the long term growth.

Complexity vs opinionated software

Reflecting back over the past four months of changes, and feedback, is that we are on a journey balancing a trade-off in complexity vs opinionated software. We started off with our initial launch being very opinionated. This was expressed in our three step wizard in the MVP launch, which we replaced and then gradually increased functionality with feedback. We wanted to make sure that we were being useful at start vs a sparse empty state and users getting lost. We hope that the empty state now makes it very easy to see what to do next, and the impact of not doing an action to "complete" the profile.

We also added in options around the most opinionated features like the abstract and eras. Then made them optional to meet the short term goal. This decision was aided by the small spike in organic sign-ups that didn’t understand and/or make full use of feature. 

This iteration on the core feature has been key to progress. Not just incrementally adding new features, but going back and improving the features already out there.It has delayed some more eye catching features that we'd like to introduce. But unless the foundations are solid no one would be using them! 

This has allowed us to make Bashfully less opinionated as we understand impact of complexity. It has also made it easier to add features without overloading that setup process. 


Smaller tweaks

In parallel to those larger changes we have been tweaking things like the homepage (pictured left). Bringing up more information "above the fold". We have also made it easier to get to your own profile. Sometimes too much thinking about onboarding can make things harder for your users!

We have also reduced the number of action menus. Initially it had made sense to have one in the profile header, but it's more standard to have a profile menu in the top right. So we have added "Manage Profile" alongside sign in/sign out. Along with a bit more personalisation with the profile picture appearing here.

We have also reduced the static pages on the site, previously we had one explaining the LinkedIn profile import and another that discussed the integrations at a higher level. This is now a single page, which is more focused around the desired outcome - aligning our short term goal to the users'. 

One of the benefits of tidying up as you go along, is that it not only makes changes easier to make but it makes the decisions about changes easier as well. The impact is easier to reason about and then test.



Import options


Branching out import options was always long term goal, and mentioned as a future direction in the last Bashfully blog post. Changes to the LinkedIn PDF export format gave us extra impetus to do it. Looks like the only reason behind change was to disrupt services like bashfully as the files were now 4 times bigger with pretty much same content! This is a big risk of tying the import too much to one service.

We also want to be open. So our export feature is explicitly shareable and machine readable. Using the JSON resume format, which we are also looking at for our API. I am actually really pleased that we added this before we needed to use an machine readable import. We aren't just paying lip service to "openness"because it benefits us. We are only custodians of the data, why shouldn't the users have full control and portability?


Further reading

The blog posts that document the MVP process at bashfully so far.

Monday, 18 June 2018

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 of management thinking")
which prompted questions about how appropriate it was to target digital products and services to older people. I then contributed my (non-scientific) observation

The response to that was about how they are a digitally excluded demographic and therefor too small a market to target. So I thought I'd dig into that and look at what might be possible if we did do more to make things if not "elderly first" at least "elderly friendly" .. could this lead to more usable and humane service delivery for everyone?

According to Newsworks research 55+ age group is a larger part of both print and overall multi-platform readership.The average time spent watching broadcast television is also greater in this age range. So you'd think with such a  large portion of the audience in an older age bracket they'd be a target right? Well, not that much. The technical adverts I see tend to be aimed at creative, edgy, urban, and an overwhelmingly young aspirational audience. If not young adults then people with young families. I would argue that brands could do more here to educate on benefits of products over the current brand differentiation, with inherent assumption about knowledge of products, that appears to be the focus.

But "aren't older users more likely to be disabled and need extra work to engage?" you could ask. Maybe, or maybe not. Even it they are and to quote "The Path Forward" blog on accessibility and startups "Disability can be split into four main areas: visual, auditory, cognitive and motor." and we can be more impaired in each of those areas to different degrees. But as they then go on to illustrate, these areas are also temporary disabilities that we can all suffer. I have been nearly deaf three times so far in my life before the age of 40, and had visual issues more frequently for much shorter periods. So if we extend how we allow users to interact with our products with good service design, taking into account disabilities, it not only opens up a disabled audience but maybe an older one as well as those that are temporarily disabled. Side note: both my parents love "Phablets" as they can read them much better than standard smartphones and I love them for watching TV on the go.

So for example, when screens aren't great for me, then I might use Alexa to control Spotify. Another great example of using relatively lo-fi tech to help an older audience is this calendar reader via SMS interface over on the Twilio blog. A son uses the technology he is happy with in his life, but then provides a interface using less advanced technology that his mother uses on a regular basis. That's a really important lesson - You can have the most advanced engine powering your product, but that doesn't mean that you can't use common and effective technology to interface with it. That's the beauty of the ease of modern API ecosystems. It allows much more creative service delivery to be designed.

There are other great projects and movements that aim to make technology improve quality of life and not just convenience for those that have the widest range of choices. For example Wayfindr is audio direction guidance that allows blind people to do things like use the London Underground. Or the concept of Mobility as a Service (MaaS) where there are various initiatives to join up transport. Uber is great for a convenient impromptu trip back on a night out, but a more reliable and joined up approach could allow many more to take complex journeys they might not currently take alone, providing them with independence.

So in answer to "Should we design better products for older people?" ... YES WE SHOULD. "Should we market to them better?" ... ABSOLUTELY! It not only opens up a new demographic market, but will make services more useful for existing users. We need to think more about customers and users as PEOPLE. Not demographics, or segments, or personas, or use cases. But real people living real lives.

I will leave you with this final thought. As today's digital natives get to retirement age how will this affect them in the future? With everything from payment to bus tickets now on smartphones are the rich now the only people who can do without one? will we retire from technology when we get older? Or will it become more invisible and fade into the fabric of life?

Monday, 16 April 2018

Further developing an onboarding process for a green field product

This is part of a series about my side project Bashfully, which aims to give graduates and other new entrants to careers a seasoned professional level way of expressing themselves through the super power of story telling. Following the core principles of being discoverable, personalised and guiding in approach.


Photo by Etienne Boulanger on Unsplash
Following on from my post on Building an onboarding process for a green field product we have building the experience. One of the lessons I pulled out previously was about launching something to get feedback. Even if you don't feel ready. It's easy to know the theory, but hard to put yourself out there!

I'm really glad that we did as it allowed some feedback and integration issues to be tested while we polished.


Background 


One approach that we have taken is to slowly refactor the experience as we add functionality into the edit screens. To start with we had a limited set of data editable. Basically the story elements. The "extras" like social links we didn't include in the first release. Now there is a unified experience, with a better underlying code base.

An interesting choice that we had to make was the "minimum" amount of detail people had to enter before "completing" a profile in the setup. In the end we decide to go with almost nothing. Make the sign up as easy as possible. 


First iteration

In the first iteration we provide no onscreen guidance and relied on the user going to "Manage profile" from the action menu. Then finding what hadn't been completed. This got me interested in empty states.

I have some experience of this with data driven applications. These are mainly the sole focus of the screen and I have tackled improving them by providing context, for example on a log out screen not only providing a log in link but directions to other brand touch points. The experience here with Bashfully has given me a bit of twist to the way I look at them. The data that was missing has three different uses, with different impacts to user goals when they are not completed.

Looking at how similar products do this, YouGov and LinkedIn give you a percentage completion figure. This can be useful in seeing how much more that you need to complete, but it doesn't give you any information on the impact to assess what to do next (if you lack time or motivation to do it all)

Second iteration

So next, we give feedback on what hasn't been completed and the impact. So, for example not choosing a profile URL means it isn't discoverable. We also choose not to spread the state messages over the profile screen, where the content should be, but to position it to the profile owner at the top of the profile text.

We've now pushed this live so that we can monitor what our users think is most important. Starting with the top three features of the site. There are other features where we can add a status indicator, for example if any skills have been tagged.


Future improvements

Another avenue we need to explore is doing something a bit more helpful with data imports. At the moment we populate the core fields in experience, but there are some ideas on how we can infer some helpful things to recommend to new uses completing their profile. Oh and extending the "LinkedIn profile import" with other integrations like Facebook, Codepen, and Dribbble.

Overall it feels like the approach of batches of experimentation at the same time that we improve the code base is the way to go. Otherwise, it's too easy to rush experiments with "temporary code" that becomes technical debt you need to worry about. The thoughtful way that Martyn is evolving the architecture deserves a lot of credit for enabling this. 

One thing we really need to watch out for though, is not gold plating the onboarding process. We need to keep an eye that experience matches the same level of functionality once completed. One way to do that is to develop another mini feature experiment while collecting data on this one.

Further Reading

Adventures with flow and transparency

Photo by  Sasha • Stories  on  Unsplash This is a follow up to my post on roadmaps and themes . I wanted to talk about experience in a B...