Agile Product Management was the subject for October’s ProductTank, with talks from Roman Pichler, Harvey Wheaton and Tom Loosemore. Agile management is an iterative method of determining requirements for projects in a highly flexible and interactive manner, and on client side projects working to budgetary requirements, rather than fixed scopes and specifications, it is being adopted by many organisations.
Roman Pichler gave us a summary of what agile product management is, and how this affects Product Managers. The product manager is effectively an Entrepreneur on the inside, an Intrapreneur. It’s hard for people to take control of the product management from the original product owner in smaller companies, and difficult to foster ideas and get them started in bigger companies. A product manager needs to be close to customers, users, developers, testers and in tune with the market.
Roman also described the beenfits of a vision statement. He explained the four key things to include are target group (using persona’s), needs (user journey’s and personas), solution (3 to 5 top level features and wireframes) and value (business model canvas). Then, use this vision statement to communicate and share the vision of the end product. Maintin it so that it’s current and keep everyone aware of it.
By using quick lifecycles (of launch, test, feedback), facilitating end user feedback early and often, validating assumptions quickly and using an ongoing larning process, the team can use agile to it’s advantage.
Own the product, inspect and adapt.
Harvey Wheaton from Supermassive Games talked about how they use agile processes within their organisation. Most games are produced in 12-18 month lifecycles, and with around 15-20 people within the game team. They focus on the first two ideas within the agile manifesto:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
Harvey explained that these two principles are more important than processes. Each new employee into the company is introduced into the agile way of working. It’s a deliberate culture to encourage people to develop and test early at the beginning of the process and to be able to speak their mind if they need to during a project.
The product backlog for each product is mapped out using boards of post-it notes which are arranged in a timeline and colour-coded to describe which parts of the project are largest. Each one represents a feature, and once that feature is complete then it goes in the bin.
Levels of functionality describe how they know the product is complete. Prototype > Alpha > Beta > Final etc.
“People will make important what you pay attention to.”
- Mike Laddin
Last up was Tom Loosemore who has been working on the public prototype of alpha.gov.uk which is an experimental prototype of a single UK Government website. It aims to be as simple as possible, and to place the needs of citizens first. The website is about bringing all of the UK government’s online information, resources, forms and transactions into a single website.
Martha Lane Fox reviewed the current approach of the government and explained that it needed revolution to get where it needed to go, and not evolution. The site was built within 10 weeks and with 10 people. The features are implemented wide and shallow in order to tackle as many different parts of the site as possible.
The site was done with limited resources, budget, space and even internet connection. Using agile product management, the team learned the top 150 user needs and prioritised 60 of them for their product backlog. They put together their own design rules:
- Google is the homepage (less than 6% see the real homepage)
- Do less
- Optimise for the common case
- Hide complexity
- Tools before content (interactive tools)
- UIDs and permanent links
- All content is not equal
- Device agnostic
- IE6 is dead
Tom also described the importance of hiring people who have a good attitude, can accept criticism and want to have open conversations, as well as how important it is to give people an umbrella to say no when required.
Overall the three speakers talked about being agile in the workplace, adapting to use what you have when you have it, and the massive importance of the environment in which agile is used. Testing early and testing often, instigating user feedback and feeding that back into the system is also important, and ensuring that big issues are fixed early can save a lot of extra work later on.
Being agile doesn’t just include process, but it’s attitude, environment, decisions, tools and culture as well. An idea which anyone can adopt, sneak into their workplace and help to improve how products and projects are run and delivered.