What’s a product manager?
As the first dedicated product manager to be hired at Arup I’ve been hearing that question a lot lately. Searching google is surprisingly unhelpful… the answers are diverse, seem to conflict a lot and you can often leave with more questions than you started with. However, when we really boil down to the nuts and bolts of it, the answers ultimately have the same core — they just don’t always use the same language. I’m going to give a general explanation here and then explain some of my key focusses within Arup.
Let’s start by talking about “products”. In the digital world a product might be anything from a simple standalone app like Whatsapp, right up to massively complex products that support big business. No matter the product size, somebody needs to be ultimately responsible– to “manage” or “own” it and to ensure it reaches and satisfies as many of its target users as possible. And that’s where the skill of product management comes in.
Part of managing a product means worrying about the high level and longer term things like pricing, long view roadmaps (i.e. plans for new features), technology changes, competitor analyses, changing users — anything that takes a long term view on how to make users PERCEIVE a product as their best option (perceive is an important term here but that’s a story a later post). A good example of this is foreseeing the need for a big shift or pivot to keep up with new technology.
The desktop Microsoft Office suite is still going surprisingly strong but it remains to be seen whether their Office 365 shift will stem the flow of people from moving to Google Docs as the world lives increasingly in the cloud. Making shifts like this at the right time is critical — too soon and you do it badly and lose users to competitors; too late and somebody else is simply too far ahead. In this example, Microsoft have mitigated the risk by making “sticky” product suites. The stickiness factor refers to how hard it is for a customer to move to a competitor due to how utterly ingrained and integrated it is in their life / network / enterprise systems.
Then there’s the detail. HOW do we approach creating a new product, or making changes or additions to one people use? What features do we give people? How do we roll them out? How do we use our developer resources to get the biggest bang for buck? When Gmail started to auto filter people’s inboxes into folders they took a calculated risk. Their product team would have known that inbox management was getting increasingly difficult thanks to the rising levels of not-quite-spam (the stuff we sign up for but rarely read). They would have seen this through analytics on inboxes as well as their own experiences and customer knowledge.
After identifying the problem somebody would have spent a LOT of time looking at the data, talking to users about whether to solve the problem and how to best solve it. So the team ended up with a set of requirements and filing rules, and worked with designers on how it should look before kicking off development work. But rolling it out was a risky business. Barging in and managing people’s inboxes can seem invasive and rude (I know that was my gut reaction). So they used their smarts and rolled out the change slowly using beta testing, and allowing people to turn it off and on and slowly the change was accepted.
Long term this proved to be an excellent plan by google. Nearly everyone uses it, and the continued rise of not-quite-spam makes it increasingly necessary, giving a new level of “stickiness” to Gmail. (Actually their feature might ultimately encourage not-quite-spam because people are now less inclined to unsubscribe but again, that’s another story and the feature was still a success).
With a small simple product one person may work across the whole PM cycle… with a large product or a suite of smaller products you generally need someone overlooking the long to medium term and one or two people digging into the detail and getting their hands dirty. This team of people will work closely together supporting one another for the ultimate good of the product and its users.
So… what does that mean for the first product manager in Arup? First of all, it’s safe to say, I can’t do all of it alone! So the team members who were carrying out the analysis work before I joined will continue to do so, with my support, until we have enough scope to grow the team. In the meantime I will focus on:
Ideas to Scope
There are a million ideas out there from the multibillion dollar idea to the ones that lose millions. Some success stories have a strong basis in pure dumb luck and timing (Whatsapp is a prime example) but most are successful for a reason. Doing early digging around an idea (but why? but why? but why?) is critical to deciding whether to build a solution and what solution to build. Digging to find the real problem or opportunity behind an idea is key to finding the best solution we can. Henry Ford famously said “If I had asked people what they wanted, they would have said faster horses”.
It’s very important here to remember the product manager is one of a very large number of people who can have ideas. Taking personal opinion out of it and listening to users and other stakeholders is far more important than having awesome ideas yourself! Owning the product doesn’t mean it’s for you — it means it’s on your head if the users and stakeholder hate it! (I may live to regret saying that)
Project to product:
Traditionally the digital team has worked on a project basis — not a product basis. However, the digital leadership team saw that huge opportunities that we have to start creating saleable products, which can meet the needs of multiple projects — instead of scoping separate digital solutions for multiple transport projects, we can scope a couple together and build a scalable “software as a service” (SaaS) solution that we can re-use later. Watch this space for details at a later date! Helping to drive that shift to how we approach some pieces of work will be a key part of my role. When we know we want to productise something up front, it has potential to change all aspects of the project from technology to the features we build initially, and the internal architecture.
Happy users / managing expectations
Anyone internal or external using something we build is someone that we want to make happy. We want people to want to user our digital solutions, and we want to avoid promising things that we can’t deliver. So as well as scoping the work I’ll be focussing on getting a better handle of our delivery timelines so we can better plan release schedules across multiple projects and products.
I hope that sheds some light on my crazy world. It’s not a small task… right now I feel like we’re at the start of a roller coaster ride… excited, slightly apprehensive and quietly confident that we’ll live through it. And come out the other side with some achievements that we’ll be proud to share with Arupians and clients alike. And lots of post-its…
