Continuous delivery for Product Owners and UX designers

It’s fun to create product and service concepts. You can use your imagination and come up with great ideas for products and their features. You can even go all out and try to validate those ideas with real users using html and paper prototypes,. Emphasizing “try”. Even at the best possible scenario you will be guesstimating based on your expertise, user’s feelings or your clients opinions. And based on this guesstimation you will be making some of the biggest decisions on your project.

Lean UX

SCRUMing it

In traditional waterfall and SCRUM projects you’re now in bit of a pickle. Your team will start working on product or a feature. And that feature is specified based on assumptions. It could be a year from now before that feature would be actually used. Or in the worst case – never. You might be building completely irrelevant feature based on client’s or user’s idea in some specifications workshop that took place some Friday afternoon half a year ago.

“But doesn’t Agile solve this problem?” Not really. By simply doing your project in agile mode doesn’t give you the real insight into what should be done. You will have more flexibility with client’s demands, which however, won’t be based on actual information, unless you are able to collect feedback from real usage. And even in that case, by using SCRUM, you can probably react to the feedback at earliest in the next sprint – which could take a month (or so).

Let clients and users know what you are doing

We have been tackling these problems by combining Continuous Delivery (CD) with Kanban board and pilot user programs. Continuous Delivery allows us to deploy new versions of the product literally in minutes with a minimal effort. Forgetting SCRUM and formal sprints we use a constantly iterating Kanban board and have weekly meetings with our clients. This means we can prioritize things constantly and keep our focus on those that really matter to our client and to our users.

Continuous Delivery and Kanban are just tools to take a real advantage of a pilot program. There is nothing more valuable for the User Experience (UX) designer or for the Product Owner (PO) than user feedback from the real usage of the product. Any amount of workshopping or usability testing will not give you the same quality of data and feedback to focus on your work.

Speed up for happy clients

Later on when you go in full production mode, Continuous Delivery will allow you to react to the feedback quickly. For example, if we get a report about a bug or a usability problem around 9 am, we see it as a critical issue and we fix it right away, we can release a fixed version of the product already during client’s lunch break around 12 o’clock. With SCRUM and more cumbersome release setup you might take this up in the next sprint starting in two weeks, wait until the end of the sprint and then release it with a bunch of other bug fixes and features. Compare – 3 hours or 4 weeks. Guess which option your client values more?

Try to fail frequently

Continuous Delivery really shines in this context because it makes failure cheap. You don’t need to spend that much time doing research on a feature as you have the option to sketch out basic functionality of the feature and try it out with your pilot users. Based on the feedback, you can iterate or scrap the feature.

All this means, you need to rethink the way of doing UX and PO work. You need to collect user data for example through analytics, feedback forms and interviews. You need to create and support a pilot user community and motivate it to use the unfinished product and to give feedback. In best case, the pilot community is a great resource for the product development and to market the product.

Continuous Delivery gives you a great tool to work with your client. If your CD pipeline is good, there is only a little effort to create also automatically updating testing servers where your client and end users can go and see the latest version of the software at any time they want. So instead of getting the specifications from the client and disappearing for months to develop the software, you will keep your client constantly informed and create an open and trusted partnership with them.

Make failing cheap with Continuous Delivery and prove Yoda wrong – try and experiment!