Categories
Product Management Thoughts

The value of good inputs

Are the projects you are working on not having the intended impact? Do you find yourself working in a company that has a great ‘shipping culture’, but all the things you are shipping don’t seem to be having the right impact? Does it feel like your customers keep asking for more improvements, more changes, while you feel you are making so many changes already?

If you feel like this, it may be that you are not getting the right inputs to help define what you work on next – what follows are some takeaways I got recently on how to potentially address some of these issues.


Last month, I attended the UXDX Conference in Dublin. At the conference, one of the speakers, Paul Adams (SVP Product) from Intercom gave a talk titled The Definition of Done. In the talk he spoke about the hot topic of Outcomes over Outputs. What really captured my interest in the talk was when he made reference to what he felt was the third (and possibly missing) component in the Outcomes vs Outputs debate – Inputs.

Then, late last month, Intercom followed that up with a conversation between Paul and Des Traynor (co-founder of Intercom) on the latest Intercom on Product podcast.

This topic of inputs, and more so, high quality inputs, really resonated with me in terms of how companies (in general) and in the software industry specifically could, and I would argue should, be using inputs across their decision making process to help inform what to build and work on next.

A ‘blue-print’ for creating an inputs-based, product development system

To start – I think it is really important to note that it was stressed in both the talk and podcast that this ‘system’ is something you should keep working on. It’s not a set and forget system – you should obsess over it and place a high value on ensuring that you get good inputs, as the value and impact of your outputs and ultimately outcomes rely on the quality of the inputs.

This is a brief summary of the ‘inputs’ system that Intercom uses themselves:

  • Vision and mission: Most often this is a one paragraph statement – what intrigued me is that Paul described Intercom’s as a 3 page document which continuously gets worked on. Personally, I do think that this is where so many companies get it wrong – they gloss over the value of a clear vision and mission, or class it as something ‘airy-fairy’.
  • Business strategy: This is where you answer how you will go about achieving your vision/mission over the next 3-5 years – and this does not cover specific projects nor is this to be confused with your vision.
  • Business goals: Here you set out the goals you have (and they can change per quarter) – things like: revenue and/or engagement targets this quarter – these help determine what ‘type’ of projects you might prioritise.
  • Prospective customers’ feedback: This comes from your sales team. They should be talking to your customers all the time, and if you don’t have a dedicated sales team in place – figure out how you can be having these conversations with your prospective customers. Don’t put words in the mouths of your customers. Don’t create fictional personas – talk to real perspective customers. They will show you the things you can build and change in your product that would help them decide to use your product vs your competitor.
  • Existing customer feedback: Finally, your existing customers are most often going to be talking to your support team. Intercom call this the CVR or Customer Voice Report and I have touched on this before – but capturing this feedback from your existing customers and translating it into a useable system which allows you to highlight customer needs is a hugely valuable asset.

So how do all these areas of ‘input’ work together?

Once you have all these inputs in place and your system is ‘gathering data’ so-to-speak, the next step is to balance out your customer feedback (both prospective and existing) against your vision/mission, business strategy and business goals.

An example of how this then works is by looking at things like:

  • Is this next quarter more about prospective customers or existing ones?
  • Is it more about try to meet a certain business goal versus strategy?
  • Do you feel behind in your mission and vision, do you need to invest some time pushing your vision forward?

But where does my decision making fit in as the CEO, Founder or SVP?

Some might argue that this system is too ‘bottom-up’ – or someone may pull out the famous Steve Jobs quote that ‘customers don’t know what they want until you show it to them’ and all a company needs is a visionary leader who tells teams what to build next.

Yes, some companies may have a Steve Jobs – they are the lucky few though. As Des said in the podcast – inputs are not something that the founder/management of Intercom thinks of:

If I look at the inputs and think why am I having this idea, and no one else is? It’s easy to think maybe our system is broken, but maybe actually it’s being traded off against something that’s way more important that I don’t know about.

And Paul shared:

People ask: what’s my role, and what’s your role? Des and the co-founders, what do they do? Paul, you run the product, and what do you do? I always explain to people, and they’re amazed by this, that our job is designing the system. And here’s what’s not an input: Des’s idea, Paul’s idea. That is not how we run the company at all.

This system is not bottom-up, this system (to me) is a great example of a cross functional and collaboratory process between all levels that takes into account both existing and potential customer needs, while balancing company vision/mission, goals and strategy.


Finally, putting a system like this in place would take time, and more so, commitment. But, as Paul mentioned at the start of his talk – the ‘software’ business is not like the road-building business. You don’t need to innovate in road building, you just need to build a good road – however, in the software industry, we have to build and ship things fast to stay relevant – but it’s no use building and shipping things based on poor inputs.

Start with the right inputs, identify those things that solve an actual customer’s needs. Building and shipping these things will create value for your customers, which in turn will increase engagement across your product, and then ultimately increase revenue.

Categories
Blog Design Product Management

Decision fatigue

Early this year I was part of a discussion around ‘how many design options to present’ and the topic of decision fatigue came up. Decision fatigue is defined as:

Decision fatigue refers to the deteriorating quality of decisions made by an individual, after a long session of decision making. It is now understood as one of the causes of irrational trade-offs in decision making.

Wikipedia

It got me thinking about the role of decision fatigue in design and further, eCommerce. The popularity and continuing emergence of ‘curated’ product offerings is a clear indication that consumers are faced with too many decisions – and they are now happy to allow a company or service to help them make these decisions. Companies are continuing to invest in building ‘intelligent’ systems that leverage the data they have on our behavior to automatically curate our experience – thus reducing the number of options we are presented with and ultimately the number of decisions we need to make. As a result eCommerce has transformed from being a – come and look at everything we have process to rather a let me recommend the right products to the right customer at the right time process.

I would suggest that as designers and product managers we need to start including a decision fatigue audit as part of our design process – and not just looking at the final product page – but rather the entire decision making process and see how we can better understand the products we are selling, the differences between them – and look at ways to better recommend these products to the customer – either by using data tools available to you – or by being bold and simplifying the options and pre-empting their decisions. Rather let you customer say yes or no –  instead of I don’t know.

Research suggests that our short-term memory capacity allows us to simultaneously consider 6-9 choices – maximum – without starting to suffer from decision fatigue. I recommend walking through your product as a user to see how well your design accommodates this research. It’s also important to understand that choice doesn’t only relate to content – the more complex your navigation and interface is the more time it takes a user to understand how it works, and what to do next.

Categories
Blog Personal Product Management

Engineering Happiness

As part of joining Automattic – you are required to spend your first three weeks in product support. I was recently part of the first group of the WooThemes team to do the 3 week Support Rotation and it gave me some key insights into customer behaviour – as well as my own behaviour  – and the way one markets/presents a product:

Engineer customer happiness and reduce open tickets.

As a happiness engineer – you are given all the tools at your disposal to help a customer with a query – as such your job it to engineer happiness for that customer using the tools at your disposal. But having said that you have to also weigh up customer happiness vs business interests – i.e. you would not just be able to refund every customer who asked for a refund with the line ‘but it will make them happy!” and realistically feel you are doing a good job. When I thought about this as a product manager I felt I could apply this same thinking to bring clarity to an often ‘grey’ job title: engineer customer happiness in a product while reducing the number of feature requests either through inclusion or exclusion.

Just because there is information online – don’t assume the customer will actually try find it first, and if they have found it, don’t expect them to have read it. And if they have read it don’t expect them to have understood it.

As a Happiness Engineer it’s your job to find the answers to the questions a customer has – often this means referencing articles that they could have as easily found as you. But, you can never expect your customer to have found these articles, let alone read it, and how about understanding them? So if you start finding that you replying to the same questions over and over again – maybe you should have a look at how and where you are addressing these issues in your products design and or messaging.

Don’t assume you have the answer to a customers question until you fully understand the problem they are facing.

We can often start telling a customer what we think they want to hear, or even more so what we want them to hear – rather than actually first trying to understand what it is a customer is asking, or why are they asking this question. I heard this line during my support rotation and it really struck me: You can put a bandaid on the problem – or you can try address the cause now.

Customers come with an expectation of what they think your product can do – and often will actually buy or use the product still fully expectant that it will do what they wanted it to do – even if it can’t.

I had a support query where a customer had a very valid idea for a website he was trying to create – but the catch was that although it was a really good idea – the way he wanted to use some of our products was just not relevant to 99% of our customers. Maintaining your products focus amongst a sea of good ideas is key, you need stay focused on your product goals and keep working towards them.