Tag Archives: product management
As a Product Manager and an Agile Enthusiast, I have lots of conversations about prioritization. It is really tricky. Well, that’s not always true. If you really only have one thing to work on, then I guess it’s easy. For the rest of us that live in the real world, we have to balance multiple number one initiatives in a way that will deliver the most value to the business. This is a first in a blog series about Prioritization.
The First Question
The very first question that should always be asked when considering something for prioritization is – Should we do this at all? People are too often moving too fast and trying to be responsive to the point that sometimes we stop thinking. One of my mentors had a saying: “This is top of mind, not top of list.” I love that. I first heard this when he called me after just having talked to an important client about a feature they wanted. He was excited and it was a good idea. I asked him if he felt like we should reshuffle our priorities and execute on this newly introduced concept. He paused and took a moment to really think through my question. And then he responded with the now often quoted “Top of mind, not top of list.” That is a fantastic barometer to keep in mind when you have a flash of brillance. It might just be a flash and you need to stick to your existing priority list. Bright, shiny objects can come into view, but they do not always warranted our immediate attention.
Having moved from Austin, TX to Des Moines, IA to San Diego, CA, I have had to learn a few things about hiring product managers. In Austin, Product Management is a well-known profession and many talented people who are either natural product managers or trained ones are available for hire. Des Moines, like many areas in the country, is not a product management town. It is full of wonderful, hard working people but with industries centered around insurance and agriculture, there has not be high demand for product management, as a discipline. This is changing, both with the enthusiasm around Agile as a software development methodology and the increasing number of start-ups in the “Silicon Prairie.” The need for product managers is, therefore, on the rise. If you are tasked with hiring Product Managers, here are three tips to help.
Comfortable withOUT a job description
For nearly every job that I have had, I have lacked a job description. Not only am I comfortable with that, I actually prefer it. And I think most natural Product Managers feel the same. Of course, we all want to know the rough boundaries around our job but we tend to be very comfortable with ambiguity. A product manager’s job may range from strategic product visioning to market research to customer interviews to tactical prioritization to sales training to process documentation and much more. What you intend to get done when you arrive at the office may differ completely from your accomplishments at the end of the day. As one of my colleagues so eloquently stated, “A product manager is the CEO of that product” and just like company CEOs, you have to roll with the punches and respond to the needs that are presented that day.
Many of the complaints that I hear often about Agile implementations concern the product owner. Either the business is not engaged appropriately, or the product owner is indecisive or unavailable, or the quality of the requirements/user stories is poor. Whatever the situation, the product owner is often “at fault.”
Instead of lamenting why we do not have good product owners, I would like to shift our thinking to: How can we build a Product Owner? These are challenging jobs and often the people put in them have little background on what is expected of them. This is the first in a series of three blogs to help us build better product owners, which will lead to better products. First, let’s examine a new product offering. Where would a new product owner start?
For this effort, I recommend a three step process and I have to give credit to David Hussman who provided some of the inspiration for this topic.
1. Create personas
Who is going to use this new product? Who is your buyer? Will you have power users and casual users? Do you need to consider administrative users?
Personas first came into the conversation with Alan Cooper’s book “The Inmates are Running the Asylum” in 1999. Personas are fictitious people who are going to use the system so the Product Owner can think about user interactions and how best to optimize the experience. Let’s map out a few personas.
Have you ever worked on something only to wonder “is this worth the effort?” “Does it matter at all?” “Does anyone care?” I know I have – and it relates in part to these blogs. In 2013, I set a goal that I was going to write 52 blogs – one per week. If you have ever tried to maintain a blog site, you know that is an ambitious goal. But I was committed so even when I would have rather been reading a book or walking the dog, I wrote blogs. And if I am honest, it did give me a sense of accomplishment when I achieved the goal.
As I worked on my 52 blogs, most were about three subjects that I am deeply passionate about: (1) Product Management, (2) Agile and (3) Leadership. I have a good amount of practical experience, I have taken awesome training classes and I have devoted time reading and studying on these subjects, so I hope that I have something useful to share.
I committed this year to write 52 blogs and I did it! There are 16 on my previous employers website and 36 on www.runyanconsulting.com. As I look back and review and reflect on the posts, here are my favorites.
Product Management Blogs
I am very passionate about Product Management and I think it is sometimes an undervalued skill set. Where I have a chance, I always try to share the strategic and practical benefits that come from having great product management resources. This year, I wrote a five part series about how to Launch a Product and recently completed a 3 part series on how to sunset or decommission a product.
I am equally passionate about Agile because I have seen how it can improve people’s job satisfaction and raise the level of productivity and effectiveness for the whole organization. This category was harder to choose my favorites, so I came up with four. First, there was a series on creating an Agile Culture and what it really means for management. This series generated some controversy, which I love because it means we are talking about important things. Next, I am surprised that many organizations are not familiar with Fist of Five. We use the Agile technique all the time and it is a difference maker in driving productive conversations. Many organizations also struggle with how to incorporate Agile into the day-to-day business, so I offered three options for incorporating bugs and maintenance into your Agile teams. Finally, I am a big believer in the sacredness of the Sprint and I believe that organizations that are disciplined enough to honor a sprint commitment will typically be more successful than those who are loosey-goosey with the guidelines.
Finally, I care deeply about leadership and family so some of my blogs were dedicated to those topics. One that has been particularly fun is documenting our evolution to an Agile Family. We have learned (and laughed) a lot together. Also, I spent some time really thinking about Innovation and what drives an innovative spirit in some people but not others. This particular blog might be my favorite of the year.
I hope you have enjoyed some of these blogs and maybe learned something new. I know that I have learned with each post and I am grateful to have the opportunity to continue growing and exploring new ideas. What is in store for 2014? Who knows for sure, but it is going to be a great year!
When we get a good idea, it is natural to jump right in and start working. In recent weeks, several people have had so much enthusiasm about their project that they want to dive right in without any real preparation or fully formed vision of what they want. To address this, here is a three part blog series on steps to take before you start. This week’s blog is dedicated to Goals – or defining what you want to accomplish. Part 2 will be defining your target audience and we will discuss personas. Finally, part 3 will define what success will look like by creating a screenplay.
But first things first. What are your goals for the project? Now, many will tell you that you have to define SMART goals – goals that are Specific, Measurable, Attainable, Relevant and Time-bound. I am going to disagree. While SMART goals are great, I don’t think you need that much structure for every project. There is a saying attributed to Voltaire which says “Perfection is the enemy of the good.” I feel like this applies to goals too. You can spend so much time trying to define metrics that are measurable and time-bound that you delay the project or miss a critical window.
Product Management is an unknown discipline to many people and it is so necessary that we must spread the word. There are visionaries and entrepreneurs out there who are coming up with wonderful ideas and then spending precious time and resources pursuing these ideas without considering some basic information first. This blog is designed to showcase a handful of questions that Product Management asks before you commit to building the “next big thing.”
1. What is the business problem you are trying to solve?
This question is usually answered by most idea people. They see a pain point and they want to address it. Awesome. As long as you can clearly articulate what you are trying to achieve, you are headed in the right directio
2. Who are we trying to solve it for?
Here is where things start to get a bit murky. Do you want to cross-sell this new product to existing customers? Or do you want to attract new customers? Do you see this product being purchased by the masses? Exactly what you build, the complexity of the product and the required feature set will all be shaped by knowing exactly who your target market is. And if you say “all consumers in the US,” you might need some refinement to your strategy.
Part of Product Management and Agile Product Ownership is to incorporate the Voice of the Customer into whatever you are building. Whether the customer is a farmer, a small business owner or a busy executive, it is the Product Manager’s job to get in their head and figure out how to solve their problems. How do you know that you are getting the best information?
Here are several methods of collecting data and each serves a particular purpose.
Meeting one-on-one with customers or prospects can enable you to collect great feedback. The trick to the interviewing process is to ask open ended questions. What is your number 1 business problem? What is the most time-consuming task in your day? What do you enjoying doing the most? The data that you can gather from these conversations can be golden. Make sure, though, that you remember that a single data point is just that. Look for common threads from several conversations and solve the greater need.
I went to a meeting last week and we were discussing how to measure a Product Owner. The concept is completely understandable, but there was something about the meeting that didn’t sit well with me so I am devoting this blog to trying articulate my concerns and things that I think need to be considered.
The premise is sound – how do you know if the Product Owner is leading you down the right path? What if you build the wrong thing? And how can you assess their mis-direction before precious time and resources are spent?
That is a 100% valid question and one that we should certainly spend time and thought to resolve. The idea that there are ratio-driven metrics to measure the PO’s performance, though, seems counter-productive.
First, I think Product Owners have a very difficult job and I think very few people are naturally great Product Owners, if you go by the broad definition. Product Owners are supposed to understand the market place, stay on top of the competition, interview current and prospective clients, and break down all of that data into meaningful features that will be delivered in order to drive the most business value. They are also supposed to be experts at writing user stories, adding acceptance criteria, understanding at least some level of the technical details associated with the application, and they need to be decisive, informed and immediately available for the Scrum Team. That is a tall order. In fact, I recommend splitting the Product Owner’s responsibilities between the Product Owner and a Product Manager, as I referenced in a previous blog.