A really rough guide to creating and validating a new product

Last month I was invited to speak at the Innovator’s Network event in Melbourne. The topic I covered was creating and validating a new product, using my experiences creating the Zendesk Connect product.

I shared the Connect story with the goal of giving attendees actionable things they could take back to their day-to-day roles. To help with that, I also prepared a handout that generalises some of the lessons I have learned creating new software products, you can find it below:


Thought process and stages
Early stages
Get usage and feedback
Build on early wins
Aaron’s Lessons Learned

Thought process and stages

Early stages

  • What problem are you solving? What’s the benefit of solving it? Why are you best positioned to solve it? Why now?
  • Do we know that a lot of people have this problem? Who are they?
  • What’s the smallest experiment we can run to see if we’re onto something
  • What result will we need to see to know we should continue? The latter can be particularly difficult to stay unbiased when setting and evaluating
  • Start thinking about getting internal support if you need it – who are the change agents within your business unit/company that could endorse this
  • Run your initial experiment with some customers, talk to 5-8 you’ll begin to see patterns
    • It might be asking about how your target customers currently do something. Maybe how they do it right now is ‘good enough’, sometimes the status quo is your biggest competition, so they are not the right person to speak to example: “How do you talk to your customers?”
    • Dig into the why and specific examples
      • Don’t let customers talk in hypotheticals and try not to go into ‘pitch mode’ – “Would you use my product?” is a bad question to ask because often people will say yes to avoid hurting your feelings
  • Evaluate what you’ve learned & tell your stakeholders about the results, including your take on what’s next – tell the narrative and use data to support your story
  • If things look positive and if you have buy-in (or maybe even if you don’t :), iterate on what you have and widen the net – now might be the time to start building a small prototype that someone could use

Get usage and feedback

  • If you build a prototype, get as much actual usage and feedback as you can from potential customers – in their workflow, with their data, in their environment, in their day to day work
    • Concentrate on who actually uses it (not those who talk about using it), how they use it, why people try it and stop using it – Observe behaviour and get on a call with people – what works? what doesn’t? Is this something they would use frequently? If not, why not?
  • Hone in on your target user/buyer – a couple of different options might emerge – decide which will be your primary focus and why
    • Building for everyone solves for no-one. If you’re building a platform for others to build on top of be extra careful – ideally have a few launch partners to build on the platform as you continue to iterate
  • Establish the next set of milestones to show that you’re on the right track to having the right solution for your target customers
  • Bring together stakeholders, in-person if possible, every so often to talk about your progress

Build on early wins

  • Keep iterating
  • Start charging – the first $ is the hardest (in the Connect example this is where we got up to, testing willingness to pay and integrating billing into the product)
  • Onwards to product-market fit – the point at which you have repeatable type of customer coming along and paying for your product/service
  • You might be onto something! Growth + profit + trade-offs

Aaron’s Lessons Learned

  • Speed of learning is the name of the game – building the right thing (product) vs building the thing right (engineering)
    • Sometimes this isn’t always clear cut because you need to build something to learn and you might want to have some engineering options in the future – Keep an eye on this and question going too far down a particular path without observed usage or patterns of behaviour
  • Make sure everyone involved knows that in creating and validating a new thing you’ll have to make trade-offs – because you want to learn fast and move fast
    • Example: the user interface for this is only going to be in English until we work out we’re on to something
    • Example: we’re not initially going to offer this to customers who have more than X million users because we haven’t optimised for speed yet
  • You’re not just building a product, you’re building a sustainable business – Article: To Succeed in the Long Term, Focus on the Middle Term
    • ie: Don’t forget the $$ even if you’re not sure of the exact details right away
  • Share the journey – What’s working? What’s not? What’s next and why?
    • Share with your team
    • Share with your sponsors
    • Share with anyone that’s interested – ‘build a tribe’, ‘running for president’
  • Set milestones along the way, track how you’re doing against those milestones and understand why you hit them (or not)
    • These could just be learning milestones but make sure you can measure against them
  • “Dogfooding” – Use the product yourselves internally and invite other stakeholders to try it, you’ll quickly learn about the real world things you hadn’t thought about
    • If people ask “can we use it?” Sure – the more the merrier
  • Don’t apply the same constraints to fledgling R&D efforts as established products and businesses
    • Beta labels are your friend
    • People will tolerate some downtime if you have a useful solution to a problem they have
      • This can depend on the maturity level of the problem domain you’re working in. Example: early customers of your new CRM system may tolerate things going down twice in a couple of weeks but customers of your new medical software might not be so forgiving
  • Find the change makers, internally and externally. How? Look for ‘agitators’, if you can’t find them try and find some proxies or things those folks might be interested in to lead you to the right people
    • Example: I looked at customers that used the Zendesk Web Widget, when finding folks to talk to about Connect because I knew they already understood embedding something on a web page and were more likely to be receptive
  • Letting go is hard but sometimes it has to be done – keep the objectives in mind
    • Marty Cagan’s two inconvenient truths about product:
      • “1) at least half of our ideas are just not going to work”
      • “2) even with the ideas that do prove to be valuable, usable and feasible, it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the expected business value.”


  • Whiteboard/notebook – always be sketching
  • Invision – for sharing clickable designs/prototypes
  • Google Drive – collaborate fast
  • Trello – light-weight kanban board – tracking customer and engineering progress
  • Inspectlet – record user sessions, watch them back, cringe, share with your team, make them cringe, fix stuff
    • At low volume – qualitative feedback can be better than the numbers
    • Another product in this space is FullStory
  • Heap – quantitative analytics
  • Our own product, Zendesk Connect – in-product messages to onboard and educate customers

Recommended by others


  • Book: The Mom Test by Rob Fitzpatrick
    • Short book, great read on how to try and validate your ideas without going into ‘pitch mode’
  • Never Ask What They Want – 3 Better Questions to Ask in User Interviews
  • Validating Assumptions with 12 UX Research Methods
  • Book: Inspired: How to Create Products That Customers Love by Marty Cagan
    • 101 for anyone in product management, I re-read parts of this book a lot
  • Book: The Innovator’s Dilemma by Clayton Christensen
    • Seminal text: why it’s hard for bigger companies to innovate and how to overcome the challenges
  • Website: http://www.useronboard.com/ and eBook The Elements of User Onboarding by Samuel Hulick
    • You know your idea inside and out but you need your customers to ‘get it’ and then actually be able to use your product. There’s careful thought needed in ensuring that anyone using your product becomes successful with it on first use and increasingly so over time

Books others have recommended to me:

  • Being Wrong: Adventures in the Margin of Error by Kathryn Schulz
  • Impact Mapping: Making a big impact with software products by Gojko Adzic
  • Lean Analytics: Use Data to Build a Better Startup Faster by Alistair Croll
  • Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden
  • User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton