Google I/O is billed as being by developers, for developers. However, with some forethought the event can also be a great opportunity for Product Managers.

Lean software development has been fashionable amongst startups for some years, but it’s still a no-go for many companies and industries. Jeff Gothelf, author of Lean UX and Sense & Respond, shares his advice on making conversations meaningful and always explaining why.

Q: What advice do you have for companies who have failed trying to implement lean?

Explain the reason for the change

If people don’t understand why things are changing they will revert back.

Change must be all-encompassing

To implement lean properly you have to change everything- culture, performance management, etc.

Experiment first, then scale up

Take a team, with a small scope, for short amount of time (month/ quarter), and let them figure out how to work in a lean way. When it works, scale up.

Throughout the process showcase wins and be transparent about what’s happening. Explain “this change made this difference because of xyz.” …

I’ve used Trello (the free list tool recently acquired by Atlassian) for anything from roadmaps to recipes, and found it invaluable for Product Management. The likes of Pivotal Tracker, Jira, Asana and Phabricator have their place, but Trello is the tool that I most commonly return to for simplicity and flexibility.

I’ve outlined 10 ways that Trello can be used for Product Management below. If you have examples add a note in the comments- I’d love to hear about them!

1. High level roadmap

A high level Trello board can help communicate your roadmap internally and externally. Do include high level features (likely to translate to your Epics). …

Presentation Roulette is a great tool for helping you think on your feet and improve your public speaking. Each participant has 3 minutes, 12 powerpoint slides and a topic to talk about. The catch? You don’t know the topic and haven’t seen the slides before. Ah yes- and the slides automatically change every 15 seconds.

The resulting event is lively, tense and feels a bit like a game show- with nervous energy filling the room and people egging each other on.

I created Presentation Roulette and have run sessions with designers, sales people and growth marketers. …

A few years ago the company I was at (Spigit) decided to build and launch a new piece of software. This software would be a test-ground for companies thinking about using their full innovation platform, so it needed enough functionality to prove the value of upgrading. The product would be designed and built from scratch, and needed to be ready in time for a launch event in four months.

Sixteen weeks later- after a lot of coding, learning, iterating, tantrums and politics- Icon was ready.

I was the Product Manager responsible for delivering Icon. This is a summary of how we did it, with recommendations for others looking to iterate quickly and launch fast with a small team. …

In 2010 I was working for the UK government, in a department that lived up to bureaucratic expectations. IE6 was used by default, paperwork was king, and expenses were submitted via a printed spreadsheet with stapled receipts. When I moved to a startup in 2011, it was a relief to start using Expensify. With its simple dashboard and easy-to-use app, expenses became a quick process rather than a painful time-suck.

Fast-forward 5 years and a couple of companies, and I returned to using Expensify. The app had changed significantly, and a quick usability test showed that what was once an easy-to-use product is now confusing to first time users. …

Software development is hard. It’s even harder if your release schedule is unpredictable and deadlines are frequently missed.

There are a few ways for engineers to estimate features. Time estimates are the simplest to understand, but they only tell part of the story.

Using points to estimate user stories gives a more complete picture of how complex each item is. Points also encourage lively discussions on what’s involved in delivering each story. However, engineering teams often struggle to move away from equating points to time.

“So one point is one hour… right?” — Engineer

After being frustrated by this process many times I tried a different approach. I introduced the concept of points with tasks that had nothing to do with coding. This helped the team become familiar with the system and kept the discussion focused on complexity instead of time. …