For those who are unaware, AMA stands for ‘Ask Me Anything’ where you’ll have the chance to ask our featured guest any question you’d like. Our product guest of honor is:

Nils Davis

About: Nils Davis currently works as a Director of Product Management at Innotas, a San Francisco-based company with a project and portfolio management product. He has also previously been a Product Management Consultant. He is a long-time product manager and his most interesting claim to fame is that he managed a tool for product managers for seven years (Accept360). That company died, taking Accept down with it, sadly, but he learned a lot about product management and product managers in the process. Since then he’s been writing about product management on his blog, and attempting to offer up helpful ideas for people on PMHQ. He’s also doing a podcast called “All The Responsibility, None Of The Authority” with fellow PMHQ member @RobMcGrorty.

His big drumbeat lately has been to help product managers focus not on products (i.e., solutions) but on the problems their products solve. A product that doesn’t solve a market problem is or will be a failed product.

On the web:

Podcast: alltheresponsibility.com

Blog: nilsdavis.com

Twitter: twitter.com/nilsie

LinkedIn: https://www.linkedin.com/in/nilsdavis

---

Select questions and answers from the AMA:

Aside from a business model canvas, what other tools / criteria do you suggest to evaluate if a problem is worth solving?

The Value Prop Canvas is useful. i.e., in my opinion, the important work is done in that one Value Prop box in the business model canvas.

But, to start with, you need to do customer research – there are lots of techniques. One good one is finding the people you think you will be helping, and finding out if they really have the problem.

Key points –

1) If you ask them “what are you problems with <domain>?” one of the top answers is your problem.

2) If you ask them “what are you doing to solve <your problem>?” and they are actually doing something, then it’s preferable to spend some $$ to do it.

3) There isn’t already a much better solution than what you can deliver

It seems like you have a lot of experience with taking user feedback into account while building a roadmap.  What are your best practices for that process?  What pitfalls should we try to avoid?  Do you have a template that you use for this?

Well, I talk to customers a lot. But more importantly, I don’t believe what they say.

I don’t have a template. Although I keep trying to make one.

Product Board seems like it might be the best product for the “template” aspect of this.

Pitfalls – believing what people say to you. You have to get to the root problem. Also, if they say they will buy, you have to validate that very hard.

The biggest thing is that it can be so much better than spreadsheets. What I mean is that having a tool that understands the product management domain is very powerful. There are all these relationships that you need to track – who asked for a feature (usually multiple customers), why a feature is worth doing (usually lots of reasons). Spreadsheets can’t represent this data. And if you can do analytics on top of that, it really helps with prioritization.

You mentioned that you historically managed a tool for PMs for 7 years and although the company didn’t work out, you learned a ton about product managers / product management. Can you share some of the top insights you learned?

My customers were product managers, so I should really understand them well, right? But no – every single time I talked to a customer I learned something new about product management, and got a new insight into how a product manager might work. I.e., “you are not your customer, even if you have the same job title as your customer.”

How do you handle usability/user testing?

Honestly, this is one of my biggest challenges. We have a complex enterprise software product. This means that some aspects of real testing only happens by real customers using their own data in production. Obviously, we do a lot of things prior to that.

We start reviewing designs very early with customers (which is OK, but not that meaningful). Then we start reviewing actual implementations pretty early as well. We open new features up to customers via feature keys, and on sandboxes, as early as we can also. But for so many of our features, they are only meaningful when running against the full data in a real world, so we never can quite accomplish what we’d like in testing before release.

So, it’s very important that – although I know “i’m not my customer” – that I put myself in my customer’s shoes as much as possible while designing and developing a feature.

For those of us that are “fresh” out of PM school (GA in my case), what advice do you have for us to market/position ourselves to 1) Get an interview, and 2) Land our first PM position…

“How do I market myself?” This is a great question that I don’t know the full answer to. But here are some things that are important to me:

1) Be a good writer. That’s the #1 thing I look for.

2) Present yourself (in your resume, in person) as you would market a product – value proposition, differentiators, then features. This sound mechanistic, but you need to do it humanly.

As a product manager, you have to interact with everyone effectively. So, be able to do that. Also, read all the other writers on how to do it, like Ken Norton, et al.

“Getting your first PM position” – usually this happens via a lateral move in a company from another role. Commonly, this is engineer, but sales engineer is a good one. Services person or customer support is another good one. Product marketing can be a route.

Another take on that stuff – in another channel I was mentioning the idea of finding an open source project that needs product management, and volunteering for that. There are lots of these projects that are just going to wither unless product management – positioning, value prop, prioritization, etc. – is done

Seems like a great opportunity. Or you could start your own project, and recruit developers. That would be a lot like product management as well.

Perhaps you already have a post about this, but how do you manage a team of product managers? Are there certain checkpoints or meetings that you have found useful in keeping the team on the same page?

“Managing a team of PMs?” Honestly, I’ve never done this. But, I do have one thing that I think is important. Managing PMs is not a PM job. That is, you’re not just a “super PM” in that case. If you’re doing PM as well, that’s separate.

The things I look for from a PM manager is a) understanding what PM is, b) making sure I have the tools and space to do what I need to do, c) helping me get better at being a PM, by making sure I have good opportunities to learn, or even making me do some learning if I need it.

The key metric, if there can be one, for managing a team of PMs is “# of validated ideas in the hopper” – that is, making sure the PMs are out getting customer feedback, that turns into innovations, that then can be fed into the product or product portfolio for prioritization.

As with any metric, you need to be very careful that it doesn’t cause perverse incentives.

How do you talk to the ignorant stakeholder?

Depends to some degree on what “ignorant” means.

You have to expect that NO stakeholder is interested in the technical details of your product. That’s only for your developers and to the extent necessary, to you.

And you also have to believe that NO stakeholder is that interested in your product unless it helps them get THEIR job done. So, for example, sales people. They are only interested in the product to the degree that they can sell it to their prospects.

The CEO? Only interested to the extent that he/she can run a business based on the revenue of your product

So, the most important thing to remember at first is that they might be “ignorant” of your product, but they are not “ignorant” in general.

So, you need to talk them about WIIFT – what’s in it for them. Of course, we’re all people, so you can’t be so bald as that.

Understand what THEIR job is, THEIR personal and practical goals, and make sure what you’re saying aligns with those.

How do you track your own progress at becoming a better PM over time? What KPIs do you set for yourself?

However, I’m always trying to learn new things, and apply them as much as I can. This is challenging, as I’m only human, like all of us. Mostly I’ve learned “on the job.” Being involved in communities like this, and having the blog and podcast, have been helpful because I have to articulate my thinking. So, perhaps that’s the best way I have?

I don’t have KPIs for myself, but I have high and increasingly higher standards, whatever that means.

I guess one more thing on that – my nature is to always try to figure out the “theory” behind things I see, whether it’s why a product happens to be successful, or why an interaction went the way it did, or even why a particular methodology works or doesn’t work. And I never assume that the surface reason is the real reason. (E.g., ask me about agile.)

How do you get Sr. Management to stick to a strategy?

First problem – getting them to commit to a strategy in the first place. It’s much easier to do product management if there’s a good, consistent strategy. Obviously, we have influence over this, like we do everything in the company related to product. But Sr Mgmt is also human, and responds to the world, perhaps on a weekly basis.

But, assuming you have a committed strategy, the usual problem isn’t them changing it, it’s asking you to do something in the product that doesn’t align. So, assume you have a committed strategy, and have worked with them to define a roadmap (theme level, not feature level) that aligns with the strategy.

Then they ask for something new. At that point you can say “How does that align with the strategy?” And you can ask, “What should I remove from the roadmap to do this?”

Sr Mgmt has a job, and that job is to direct the company towards success. If they change the strategy, they (might) have a good reason for doing it. So, that’s obviously something you need to understand as well. But, if the strategy change is not a good idea, or the new feature request is not aligned with the strategy, at that point it’s you and your persuasion skills.

And sometimes you just have to do the new feature, unfortunately.

There’s a whole set of things we can talk about when that happens.

What are your thoughts on agile methodology?

“Agile?” LOL. OK, so I have a very simple framework for agile. Agile means “make a list of the things you want to do, in order of importance. Do the first thing on the list. Check the list, and reorder it if necessary. Do the first thing on the list. Repeat.”

My definition has nothing about sprints, or scrums, or story points, or anything like that. It’s about doing the most valuable thing first, and then doing the next most valuable thing.

Now, there are some methodologies that can help you do this effectively – scrum, kanban. Really, any type of project planning approach.

The most important thing about agile is that you’re NOT doing the following: “make a list of all the things we want to do. Order that list in the most efficient order based on time estimates. Do the things in that order.” That’s “waterfall” and it’s all about time efficiency. But it says nothing about delivering value fast.

So, if you pivot from efficiency to value, you get agile. And at that point you don’t need to worry about time efficiency – your team will get the most valuable stuff done as fast as they can.

The better the team, the faster this will be, all things considered. But it’s not because they’re agile that they’re getting them done fast, it’s because they’re good. Agile is putting value first, team quality is about getting that value out fast.

One of the best books on agile, imho, is Dean Leffingwell’s “Scaling Software Agility” – he compares various methodologies for making enterprise software (not necessarily products)

Oh, and a good methodology can help the team get faster through various modalities – learning, pair programming, feedback

And you keep on doing that.

One of the key things when you go agile is that you no longer are trying to predict (as far into) the future. It’s hard enough to predict where you’re going to go for lunch. Predicting a technical outcome, especially for an innovation, more than a few days to a few weeks in advance is guaranteed to fail.

How did you get your first PM gig?

I started in PM from technical writing. I was working for a company that was marketing their product in an inefficient manner, so I made some suggestions. Suddenly I was a product manager. This was before people really knew what that was. Since then I’ve been trying to figure it all out.

That product also failed, due to a fundamental reason I realized later. It was in Ai, which at the time was not solvable (it may still not be solvable). Our tools got you closer to a solution than all the alternatives, but in the end it remained unsolvable. So, it was never going to fly.

What is your favorite thing about being a PM?

I love most things about product management. In fact, if you listen to the podcast I linked to, I have all those characteristics. I like talking to people, I’m good at talking to lots of different types of people, I like have all kinds of stuff going on and get bored doing the same thing for more than an hour, etc. But, it’s also, I think, the most important role in any company – product managers are essentially responsible for the top line revenue of a company. Companies sell products. Products are brought into being by product managers. It’s fantastic! (If it goes well…)

Do you have a prototyping workflow that you recommend?

I am open to lots of different approaches. I personally am not good at prototyping, although I often will offer up my own terrible prototype in Balsamiq so my designer has something to push against. At Innotas I work with a designer who creates wireframes with Omnigraffle.

We iterate on those a few times – and this year I’m hoping to move to interactive versions of these. this is both internally and with customers. Then we start making product when we’re in agreement.

I’d like to improve this process some this year – like I said, moving to interactive prototypes that we can have users actually interact with would be the first step.

As I mentioned above, we have a complex enterprise product, so getting user testing on partially-working stuff, or on prototypes, is useful, but not as meaningful as one would hope.

---

Interested in being part of the conversation with the world’s top product leaders? Check out future AMAs in the Product Manager HQ community.