Early in my consulting career I got the opportunity to lead a small product development project for a new client. I was excited and arrived at my clients office to have the kick off meeting with the partner in charge. We grabbed a cup of coffee and sat down to discuss the project. She only asked one thing – ‘I want no surprises’ – she didn’t care what the risks or issues were as long as we discovered them asap.

Looking back I’ve realised how much these words have helped shape my approach to product development and the software development life cycle. I always try to flush out the surprises early on in Sprint 1. This means that I like to focus on the following areas during the initial few sprints of any project;

1. Identify the internal dependencies between various product teams (i.e. back end API and the front end developers) and rank them by potential risk
2. Identify the external dependencies you have on external suppliers and teams and see how quickly they respond to your requests for support and change requests.
3. Identify what new languages, technologies, tools or 3rd party solutions you are planning to use and make sure these are included in Sprint 1. For example if the team wanted to introduce a new DB like Redshift or use a new language like GO that they have not used before I would flag this as high technical risk and ensure these were included in my earliest sprints.
4. Deliver a very narrow ‘end-to-end’ vertical use case which would allow your end user to touch most major parts of your product. For example, create a ‘to do’ task via the front end, pass it to the back end via an API, save it to the database and then generate an activity report. You will probably be embarrassed to show it to users as it is so buggy, ugly and slow – but it will help flush out several surprises.

As you may have deduced by now the goal is to to identify and tackle the biggest assumptions and risks from day 1. This may mean trading ‘perceived’ short term productivity to instead unearth 80% of the surprises you will encounter during any product development project. Here are some common surprise that I’ve discovered by taking this approach;

• People: This first sprint will often feel a bit chaotic to teams that have not worked together before. Arguments and stress levels may rise as people feel forced to take shortcuts and introduce technical debt. This is ok and healthy when it comes to developing high performing teams (the Storming phase before the Performing phase in this study of team dynamics). This helps your team discover how to handle stress, conflict and internal disagreements in a relatively safe way. Overall I’ve found that despite these hiccups it quickly brings a team together as it allows for early collaboration, compromise, and an understanding and confidence in each others ability.
• Customer: By delivering at least 1 very rough and functional use case you will now have something to test with your earliest beta users / customers. Most product users will have little experience of working with agile development teams at this stage so this helps you educate users on your process and identify the true early adopters in your beta group. Users may be initially disappointed at how crude your early iterations look and feel – especially if they have little experience in new product development – but once they get past this you can still get valuable feedback and ideas for course corrections and priorities for the next sprints. This super early engagement helps build trust and excitement with users as they rightly feel ownership over the solution which helps with adoption, retention and referrals when you launch your crucial early beta.
• Process: There is nothing like real data to test your product. By tackling your biggest assumptions and risks early on you can better react and adjust to surprises. You may need to go back to the drawing board on several assumptions so the earlier this happens the better. This gives you more confidence in your estimates, planning and overall product development process

What I’ve outlined here is part of my strategy to discover surprises as early as possible during product development. Remember there will always be big surprises on every project, so why not discover them as soon as possible when you have a chance to do something about them and ensure they don’t derail your long term success.