Create a Customer Journey map

Too often we build software intent on creating features instead of  solving real world problems. We sit at our computers, maybe working with other departments, and create a list of things that we’ll build into future releases.

While new features are great and may even be world-changing, I suggest getting to know your customer a little bit more before trying to build stuff for them. Enter the Customer Journey Map.



This is a recent map I built for a product I thought I understood well. In one view you can see what a user is doing, thinking, and feeling in each stage.

I didn’t have to complete the map to see some of our deficiencies. The very first time someone hears about BombBomb it’s usually a referral from someone they know. But in the last step, at the user’s highest sense of euphoria, we’re not doing anything to encourage them to spread the word. A complete disconnect.

Creating a map like this takes time but is well worth it. When you put in the time your users will thank you.

Iterate Your Way To Better Software

The best way to hit a home run with your software project is to constantly release small improvements. While you should always keep your aspirations in the clouds, forget hitting upon the one best idea on your first release. Instead, keep building, assessing, planning and building some more.

We recently overhauled a page on the BombBomb web app that displays your contacts grouped into lists. It’s definitely not the best it can be and we have a long list of improvements we’d still like to do, but it’s a start and it lays the groundwork for future iterations.

With an iterative mindset it’s important not to get in the habit of moving on after a release. You’ll find the big wins when you dive into your analytics to see what’s happening and your user testing to see what people are thinking. Use that data and keep making improvements.

Accountability and Scaling a Product Team

Intercom published a fantastic post on building software and scaling a product team. Of particular interest are these point on accountability.

  • If the analysis of the problem to be solved is incorrect, it’s on the PM. Ensure appropriate research is done.
  • If the design doesn’t address the problem, it’s on the Designer. Ensure you understand the research and problem.
  • If the design solves the problem, but doesn’t fit with Intercom, deliver best practices, or is otherwise weak, it’s on the Designer. Ensure you understand our beliefs, patterns and principles.
  • If engineering doesn’t deliver what was designed, or delivers it late, it’s on the Eng Lead. Ensure you understand the problem being solved and design, plan appropriately and accurately before writing code.
  • If it goes out with too many bugs and broken use cases it’s on the PM. Ensure the team test realistic usage and edge cases.
  • If the team is spending too much time on fixing bugs and not adding new value per our roadmap, it’s on the Eng Lead. Ensure each project improves overall code quality.
  • If we don’t know how it performed, it’s on the PM. Ensure success criteria are defined and instrumented.
  • If it doesn’t solve the problem, it’s on the PM. Ensure there is a plan to improve product changes that don’t fully solve the problem.

This isn’t done to post blame but rather to assign ownership. If something is breaking down on your team, try tracing it back to one of these accountability issues.

Test Early and Often

Yes, it takes longer for development to begin working on a project if you focus on building prototypes and testing with users early. But you ultimately launch products faster with a higher success rate when you put the effort in early.