All The Process You Need (With Real Pictures)

Three core ingredients

1. It Starts With The Customer

There is always too much to do so the only really effective way to prioritize things is around what creates value for the customer/user.

Sometimes it is tempting to park this for a while and focus on your own problems, but the customer does not care about your stuff and if you are not solving their problems someone else will. In short, unless the house is literally on fire, the product and tech team have to ensure there is always a way to improve the customer facing products.

A constant always-on stream of UX research is key to keeping the customer problem front and centre. This research is about uncovering new problems to solve, validating possible solutions and also keeping an eye on the current products through regular user testing to keep them evolving.

2. Understand What Drives The Business

Understanding the problem you are solving is half the story. The other half is how you make money from solving this problem — otherwise we just go home now!

What are the basic economics of the business, what are the key metrics. At Just Eat these for a while we had 6 golden metrics we all knew were the ones that we had to move. But also other data points: Which acquisition channels need optimisatised for, where are the highest margins, where are the most costs.. A great way to get to this to map it all out on a massive wall and walk new joiners through this!

3. Empowered Cross-Functional Teams

This is the fundamental unit of delivery. It is impossible to make change unless we are all moving in the same direction. A team is not a organisational hierarchy, rather it's a collection of people who come from different parts of the organisation unified by their commitment to a single mission: A problem they need to solve that creates value for the customer

A pure cross-functional team is hard to create organisationally, so a halfway house to support good product development is to organise on a core and satellite model with the prod, design and engineering function at the core, but regularly bringing in the relevant commercial people, UX research and analytic people to support discovery sessions for new ideas and agree on the best ideas around how to progress the mission

And A Recipe For Success Based On High Transparency & Regular Cadence

Once you know the customer problems, know how you make money and have put in place the teams you then need to establish a framework for building the products and then making them great products. There are 100s of books and conference talks about this, but below are the basics.

Sprint Demos

Kanban, Scrum, whatever! The team can decide this. But there needs to be a block of time around this — typically 2 weeks — bookended by a planning session to agree on the scope and a demo of working software at the other end.

The demo should be regular and always be there, even if there is not much to show! It should also be open to all who are interested.

Typically product, UX and engineering/QA present the work of the sprint:

• Product = sprint goal, why the work matters*, roadmap in now, next future format
• UX = Designs and why this and not that (based on user testing)
• Engineering/QA = Demo working code
• Delivery = Burn-up charts

*why we think the work matters, but not necessarily evidence of values created or that it makes a difference as this can take time to collect, see below “Showcases”

Fortnightly Big Board Syncs

One of the most important processes there is for managing the work on the teams was the weekly big board meeting. The board tracks all the work on the teams: Done, WIP, ready to go and backlog:

Every week senior tech and product leadership would meet with delivery and review what was going on:

• What dependencies need to be chased down
• How much WIP is there on any one team
• Is the «ready to go» work scoped small enough and ready to develop
• Is there enough validated work in the backlog

Surgeries

Regular meetings 1:1 or with small groups of senior stakeholders to build trust: By providing updates on progress, sharing future thoughts, aligning on areas of focus and triaging bugs. With these in place, the roadmap is more a constant conversation than a fixed document that has been signed off on

Showcases

These happen monthly and their purpose is to provide an update to the whole company on how the products are evolving to support the strategies and deliver value to the customer.

They cover what has been released by the teams in the sprints, but they are 100% focused on the value created and delivered. And their main job is to clarify how this supports the product’s evolution and aligns with the strategy.

Every team is then focused on the story they are telling over a quarterly/6-month timeline. Typically product lead on the presentation here, but it’s good to opt in to whoever you need to tell the story; UX, customer voice, Sales people, engineers, etc.

The main point of these sessions is to draw a bold line between the company’s strategies, and the work on the teams and support the story of progress with quantitative and qualitative evidence that is engaging and accessible to a wide audience. For the details, there are other forums: Surgeries and strategy discussions so don’t feel you need to get into everything at this one forum – But also have it ready to answer questions!

Side bar on showcase comms

While it is important to communicate through presentations other channels can’t be ignored.

Blog posts: It’s good practice to write up key showcase content as a blog post that you can reference when you get asked what the teams have been doing. But of course not everyone reads blogs so these are never a substitute for actual conversations with key people.

Impact cards: These are one slide that summarises what’s been shipped, why and the impact to date. They need to be specially made and not just be pulled from the showcase deck as they need to be readable without voiceover and easily be shared via Slack or teams to catch the people who missed the showcase and are perhaps too busy to read the blog post. A good format is: Picture, chart and quote (something you can see, something measured and some evidence of emotional impact)

Pantomime: Not obvious, but important. Sprint demos need to hold attention and also people also set aside time to attend them. So don’t just read through the release notes while you show the software, take the opportunity to get creative and make people pay attention and really understand what has been achieved and why.

* Simplified a data flow: Show the old flow with string or a picture then show the new one.

* Made a process faster: Ask people to race through the task on the old interface vs the new one

..use you imagination. Work is serious but it does not need to be dull!!

Quarterly OKR / Goal / Bet Setting

It almost does not matter what framework you choose, but it does matter if you do not have one!

The OKR framework is the go to one for most companies, alternatives are to use bets and a framework called the Lean Value Tree or this is another good one: https://basecamp.com/shapeup

Whatever you choose every 2 to 4 months you need to get offsite and reflect on the past few months and set some tram lines (define where we play and where we don’t) for the next cycle

It is good to do this with as much of the extended team as you can and its good to run these over a few days. The approx agenda is:

• Day 1:Leadership set the context and high-level goals
  Teams and extended team members huddle and draft a high-level road map
  Break out into discipline groups (UX, BA, etc) and talk about issues that need covering (security, pattern libraries)
  Have dinner together!
• Day 2: Regroup in team huddles, and re-check roadmaps to feed in anything learned from the cross-discipline sessions.
  In the afternoon teams present back Roadmaps.

All Hands / Company Wide Comms

Ideally everyone in the company needs to be working to a common set of goals. You can’t repeat these often enough and you always need to show how the product is progressing and where it is going to

The main point at the all-hands is to provide the whole company with a clear and structured view of the strategy, the actions and the plan. And see how each teams work clearly linked to an objective that is linked to the mission.

Ideally where you are going part is represented by some kind of visual artefact, perhaps a high-fidelity prototype or a video piece describing how the future could look if we push our product and business to its logical conclusion. This should be inspiring but also rough and far out enough to be clearly unachievable in the near or medium future to avoid it confusing people about near and medium-term goals.

FAQs

Why no business requirement documents and business sign-off?

There is a place for a version of these things. Artefacts like narratives where a few pages to set the scene and get everyone on the same page about the goal. Also, this is a great alternative that is used at Miro to align on the goal.

But really once you have the goal it should go down to the team to get you to the outcome. The product manager is on point for most of this but it's everyone’s priority — which is why it’s best to avoid teams with multiple goals or significant players who are also in other teams.

As for business sign-off, in an ideal world, you have employed a product manager and they are paid to be trusted and accountable for the decisions they take. In practice the good product managers are always working to build consensus and alignment, awesome at comms and will of course check in with key stakeholders on the big calls. But formal business sign-of is slow, cumbersome at best, and at worst locks a team into a commitment without any evidence that that commitment will solve the problem. Far better to trust the team who were created to solve the problem and hold them to accountable for the outcome.

If as a business you are still nervous start with small problems and short timelines, then move from there

What About Bugs?

The harsh reality is not every bug gets fixed: Only affects 1 user in 1m, has an ok workaround, etc, and would cost more to fix than we lose in revenue. But at the same time even small bugs make a bad experience.

The trick is to fix them as you go without overwhelming the team so that this is all you do. Assuming the house is not on fire the basics of this are about creating good friction: Have a robust process for triaging bugs that come in at the first line, have support analysts raise the top priority bugs at a start the week meeting and move them into a small fix stream or into the backlog based on complexity and severity.

If the house is on fire then it is about incident handling and this is way beyond the scope of this article.