Five things I look for in Product Managers

SaaS companies live or die by the quality of their product managers.  Great ones really power the future of their companies.  Not-so-great ones waste precious time and investment resources.

It’s very hard to tell from a resume, however, who is going to be a great PM. Great product managers can work for not-so-great companies and vice versa. And what people with this job title actually do varies wildly from company to company.

 

I have been involved in hiring product managers for the past 10+ years. I have hired some great ones and I have made some mistakes. Over the years, I have learned that there five key things that really make a difference:

 

1. Ability to think like someone else

 

Product managers are trained to identify user types or personas. These include information about users’ day-to-day experience, mindset and needs. It’s important to be able to do this, but to be a really great PM, you have to be able to take the next step and actually think like customers, and internal stakeholders as well.

 

I want to see that they can actually put themselves in the position of a user, of a salesperson, a support agent, or other product stakeholder in their company. That they can get into their heads, almost as if they were actors in a play.

 

The best product managers have a tremendous amount of empathy for other people. They can forget about what they think they know about how to use, sell, or support their product and put themselves in the mind of someone who lacks all of that context and has a very different set of day-to-day concerns than they do.

 

During an interview, I test for this by asking the candidate about how users and other stakeholders thought about the products and product development ideas that they worked on. I ask them what surprised them and what they learned from it. It’s not hard to tell who has this ability because those who do exercise it regularly and those who don’t find it hard to come up with examples.

 

2. Determination

 

The most effective product managers are creative and innovative thinkers with positive mindsets. They do not give up. They see the positive outcome as expected and they are surprised by failure. And they see every partial failure as success in need of small refinements - even when there are gaping holes to fill.

 

A lot of today’s most popular products should have died a dozen deaths, but somehow they made it. They made it because their PMs would not give up.

 

Often in an interview, I will give the candidate an example problem of a now-famous payments product that had so many obstacles to overcome in its original conception that people laughed at the idea.

 

I ask the candidate to imagine what it might have been like in the early days of that product, and what problems may have arisen and how they would have tackled them. Their answers show me both their analytical ability and their ability to suspend disbelief and persevere.

 

3. Cultivator of great ideas

 

In most of my product manager interviews, I ask the candidate to tell me some of the top ideas in which they’ve been involved.

 

What I’m looking for here isn’t a detailed explanation of what the person has come up with themselves. Instead, I want to hear about the ideas and products that they helped develop. The best product managers have an uncanny ability to be part of conversations that lead to great ideas. To use a sports analogy, I am less interested in how many points they score individually. Instead, I’m more interested in how much their team scores when they are in the game.

 

To test for this, I ask them to describe the process for developing the top ideas that they mention. I probe to learn about how others were involved and how they helped make sure diverse perspectives and expertise were brought in. If all I hear is “I” and simple logic (talking about done ideas), I know I do not have a great PM in front of me.  Similarly, if all I hear is “we” and I don’t pick up any original contribution from the person I am talking to, I know I am not dealing with a potential game changer.

 

4. Organizing force

 

Great product managers are organizing forces. Note that this is not the same as "being organized." It means that they help define problems in a way that they can be solved with simple solutions and they help develop designs, requirements, and plans so that the teams they are part of can be organized. How product development work is organized and how team members understand the structure of the work is critical. Great PMs can make a night and day difference to the performance of their teams just due to the fact that they help them structure their work better.

 

To test this in an interview, I ask candidates how they would handle a complex product development challenge from my past experience. I ask them to come up with options for how to structure and sequence work, what information they would need to choose among them, and how different stakeholders would understand the approaches.

 

5. Inspiring

 

One of the biggest challenges faced by product managers is how to inspire people who aren’t their direct reports to do things in support of product development efforts. Product managers work across organizations, from engineering to marketing, support, finance, and beyond. It is imperative that they are able to connect and motivate people cross-functionally.

 

In an interview, I will ask them to share past challenges they had with people who had different priorities, and how they were able to motivate the team to get things done. I look for the signs of earned authority - the ability to build followership and commitment to shared goals.

Finding all of these qualities in one person is rare, but I have found that if I probe into each of them I can get a nice well-rounded picture of where a product manager is in their development.  And those who are strong in each of them are a joy to work with and great assets to their teams.

Put on your own mask first

Difficult times are the ultimate test of leadership. These are the times when lifelong bonds can be established or connections can be lost. Deep human connections are all ultimately based on faith. Faith that through them strength, security and growth will come. Leaders need to ground that faith in confidence, consistency and an unfailing positive attitude.  

At this moment, many leaders have been put in the impossible position of having to show confidence when the foundations of their businesses, their markets and the global economy are being challenged. It doesn’t work to try to hide things or to spin things or to simply put on a happy face. What people need from their leaders today is authentic confidence. That is what leaders have to reach deep down to find right now. The great ones always find it and their connections are strengthened as a result.

Hipparchus 1.4 Released

We just cut another Hipparchus release, which should now be available on Maven Central.  Hipparchus is a library of lightweight, self-contained  mathematics and statistics components addressing the most common  problems not available in the Java programming language. 

New features and enhancements include:

• Bilinear interpolation for 2D grids
• Field version of sinCos
• Support for complex ordinary differential equations (both primary and secondary equations)
• Accessors for state transition matrix, Jacobian matrix H
• Innovation covariance matrix and Kalman gain in Kalman filters
• Three-dimensional field arrays
• Several fixes in the Euclidean 3D and spherical 2D partitioning 

The release is available on the Hipparchus download page.  The release jars are available from maven central with groupId org.hipparchus and artifactId by library component.  For example, the ODE jar is here:

<dependency>
  <groupId>org.hipparchus</groupId>
  <artifactId>hipparchus-ode</artifactId>
  <version>1.4</version>
  <type>pom</type>
</dependency>

Bug reports, patches, suggestions for improvement are always welcome.   Subscribe to our mailing lists and dive into our source code to get involved.

Read the proofs!

Now and then one of my friends asks me for recommendations for books to use to re-engage with mathematics.  I am always happy to help and I try to come up with recommendations that will be "goldilocks hard" but also interesting and fun for the person who is asking.  I also selfishly think a little about what it will be like for me to talk about the book's content with my friend.

I look for books that motivate the material well, but also actually prove things and I always make a point of telling my friends that they have to read and understand the proofs, ideally well enough that they can reproduce them.  Today I asked myself why I always make such a big deal of this.  Here's what I came up with:

1. Mathematics is a progression of ideas, expressed in arguments that prove results.  The results are often useful in solving problems, but the arguments are really where the mathematics is.  If you understand the arguments, you will be able to do problems - often in many different ways.
2. Proofs show exactly what is needed to get results.  They show you, therefore, exactly where the limits are in applying the results.  When you understand a proof, you know exactly what you have to work with.
3. Proofs are rigorous and often hard.  If your goal is to be able to apply mathematical concepts and hone your mathematical intuition, working through hard proofs is much better training than just practicing algorithms.  
4. What you can prove in mathematics is what you know.  Results that you can apply, but don't understand the proofs for, are what Plato would call "true opinions," not knowledge.  Not grounded in proof, your understanding of algorithms and their valid application might "fly away" at any time (See Plato's Meno 97-98, for a delightful account of this).
5. Go back to 1.  The beautiful thing about studying mathematics "for fun" is that you get to actually do it.  Under time / grade / getting applications done pressure, the mathematics ends up taking a back seat to the applications.  It's like fast-forwarding the show and watching the commercials.  Coming back now, you can actually watch the show.

So read the proofs!

Hipparchus 1.3 Released

Today we cut another release of our little Java mathematics library.  Hipparchus is based on a fork of Apache Commons Math.

The 1.3 release includes some nice new features - most notably a redesigned Kalman filter implementation capable of handling nonlinear processes, along with quite a few additional enhancements and bug fixes. 

• Support was added for complex eigenvalue decomposition.
• A solver for continuous time algebraic Riccati equations was added.
• Secondary equations can now update the derivatives of the primary equation in ODE.
• A matrix decomposer was added to allow configuration of decomposition thresholds independently of the matrix.
• FastMath was extended to cover the new Java 9 methods so it can still serve as a drop-in replacement for java.lang.Math.

I had fun fixing some bugs in the stat package and reviewing the Kalman filter design and implementation.  One of the bug fixes, for the Mann-Whitney test implementation, included implementation of exact computation of the sampling distribution of the Mann-Whitney U statistic.  The algorithm for this is nice and simple, but it does not handle the case where there are ties in the data.  I have started working on generalizing the algorithm (to some extent, the definition, actually) to support this.  Comments, patches welcome!

The release is available on the Hipparchus download page.  The release jars are available from maven central with these coordinates:

<dependency>
  <groupId>org.hipparchus</groupId>
  <artifactId>hipparchus-aggregator</artifactId>
  <version>1.3</version>
  <type>pom</type>
</dependency>

Selling the truth

This month's Significance magazine includes a jarring article about fake news.  As one would expect in Significance, there is interesting empirical data in the article.  What I found most interesting was the following quote attributed to Dorothy Byrne, a British broadcast journalism leader:

"You can't just feed people a load of facts...we are social animals, we relate to other people, so we have to always have a mixture of telling people's human stories while at the same time giving context to those stories and giving the real facts." 

Just presenting and objectively supporting debunking factual evidence is not sufficient.  We need to acknowledge that just as emotional triggers are key to spreading fake news, so they need to be considered in repairing the damage.  I saw a great example of that in yesterday's Wall Street Journal.  An article, titled "Video Contradicts Kelly's Criticism of Congresswoman," sets out to debunk the fake news story promulgated by the Trump administration claiming that Florida Rep. Frederica Wilson had touted her personal efforts in getting funding for an FBI building in her district while not acknowledging the slain FBI agents for whom the building was named.  The Journal article could have stopped at the factual assertions that she had not been elected when the funding was approved and that a video of the speech she gave includes her acknowledging the agents.  But it goes on to provide emotive context, describing the Congresswoman's lifelong focus on issues affecting low-income families and her personal connection with Army Sgt. La David Johnson, the Green Beret whose passing ultimately led to her confrontation with the Trump administration.  The details on how she had known Sgt. Johnson's family for generations and that he himself had participated in a mentoring program that she founded provided context for the facts.  The emotive picture painted by the original fake news claim and the administration's name-calling "all hat, no cattle" was replaced with the image of a caring human being.  In that light, it's easier to believe the truth - that Rep. Wilson was gracious and respectful of the fallen agents and their families just as she was of Sgt. Johnson and his family.

The lesson learned here is that in debunking fake news, "factual outrage" is not enough - we need to focus on selling the truth as the more emotionally satisfying position.  As the Significance article points out, people are drawn to simple explanations and beliefs that fit with what they want to be true.  So to repair the damage of fake news, we have to not just show people that their beliefs are inconsistent with reality - we need to provide them with another, emotionally acceptable reality that is closer to the truth.

Five things I look for in Software Engineers

I have been interviewing a lot of software engineers recently, as I am leading a new team and looking to expand it.  That has led me to reflect a little on what I am actually looking for.  The following five qualities have been shared by all of the really good, fun-to-work-with developers who I have had the pleasure to work with.

1. Technical mastery

Really good developers fully understand what they are doing.  This might sound funny, but unfortunately, it is all too common for people to get things to work by cutting and pasting examples or fumbling through a quasi-random hacking process to arrive at code that "works" without actually understanding how or why (or in fact even if) it works.  There is nothing wrong with experimentation and leveraging experience - and working code - of others.  When really good developers do that, though, they always find their way to full understanding of the technologies and techniques that they are using.  When I interview developers, I always ask them to explain exactly how the solutions that they developed work.  I can usually tell very quickly if I am talking to an individual who masters the technology that they use.  I would much rather have a developer with strong mastery of a small set of technologies than someone whose resume is full of advanced technologies that they don't understand.

2. Simple mindedness

In The Humble Programmer, Edsger W. Dijkstra said "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague."  Really good developers have a wonderful tendency to keep things as simple as possible, as long as possible.  Fancy constructs, excessive OO complexity, needless external dependencies and exotic algorithms never find their way into their code.  If there is a simple way to do something, that is what they do.  Reading the code of a simple-minded developer is like reading a mathematical paper written by a great mathematician.  If the content is straightforward, the progression is 100% predictable.  You can stop in the middle and scribble out what should come next and then see that is what comes next.  When you get to a difficult part where you have to think, you are happy to see that the author found something so simple that you should have thought of it.

3. Organizing

Another one of my favorite Dijkstra quotes is that the art of programming is the art of organizing complexity.  Great developers are organizing forces.  Note that this is not the same as "being organized." It means that they help define problems in a way that they can be solved with simple solutions and they help get contracts, interface boundaries and tests in place so that the teams they are part of can be organized.  The scope of what developers can organize naturally grows as they progress in their careers; but they need to have the drive and ability to be "organizers" from the beginning.  Developers that have to be told how to think about problems are net drags on the teams they are part of.  Good ones are key contributors to their teams arrival at nicely organized approaches to problems.

4. Fast-learning

Technology changes so fast and business problems are spread across such a large surface that developers constantly need to learn new things.  And these things are not just programming languages, frameworks or constructs.  Developers need to learn business domain concepts, data science and AI concepts as needed, often in ridiculously short timeframes.  This means that they have to be able to learn very fast.  And they have to be able to do this and immediately exercise their knowledge with a high level of independence.  Its great to be able to learn together and share knowledge with others, but sometimes developers need to figure things out for themselves and good ones have the ability and determination to learn what they need to learn - however hairy it gets - to solve the problems in front of them.

5. Situational awareness

Good developers ask about - and clearly understand - the execution context of the code they work on.  If something needs to be thread-safe, they write it that way.  They know what the performance and scalability bottlenecks in and around their code are.  They know about its security context.  They see enough of the larger system that their code is running in / interacting with to ensure that it will be operable, failing fast and loudly when it needs to fail, maintaining invariants that it needs to maintain, and providing sufficient logging / events / monitoring interfaces.  And of course, all of this is validated in unit tests.

I know some people will say that some of what I have above - especially in 3. and 5. - can't really be expected of "SE's."  These qualities, one might argue, are qualities of architects.  Developers just need to be "feature machines" and architects can worry about how to organize the code and make sure the whole system is operable.  My biggest learning in 30 years of software development is that that is the wrong way to think about it.  Architecture influence and scope of vision naturally increases as developers progress in their careers; but it is part of what they do, every day, from day 1 and the better they do it, the more successful the teams they are part of can be.  And the senior ones - those who might have "Architect" or "Principal" or "Staff" in their titles - need to encourage, cultivate, challenge and be influenced by the design thinking of SEs at all levels.