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.