How to bring product mgmt to an organization

Apply Design Thinking to your new responsibility. Stop focusing on the Herculean end-goal, as that is almost a gravity situation that you cannot solve for. After following the previous comments' advice understanding where you and the organization are today, including identifying pain points, you need to start with small (think Scrum user stories here) problems that can be solved with immediate actions. As you start solving the immediately simple problems, the harder larger problems may become less daunting and action steps toward those problems will likely come into clearer view. Don't be afraid to experiment. Don't be afraid to admit publicly that a solution failed and now you will be trying another solution. As time goes by, openly communicate out your successes, failures, and next steps, asking for feedback from all level and discipline of colleagues. That communication will rally supporters and people who want to get behind your leadership to collaborate and help. Sounds easy right? It's not, but thinking this way will prevent you from feeling overwhelmed, which will lead to pride and fulfillment in your new job, which will lead to quality results and followers.

In response to: 

The Serendipitous Career Path

At the NFAIS 2017 Annual Conference Program, Judith Russell, Dean of University Libraries at the University of Florida, referred to her career path as the result of serendipity. I found this fascinating and refreshing at the same time.

We live in a world where children are commonly asked, "What do you want to be when you grow up?" and where college students (and their parents!) often stress over what major to pursue, and where employees are yearly asked, "Where do you see yourself in 5 years and what are your goals to get there?"

Additionally, take into consideration and combination the career advice I've received in my life. "Work hard and you'll get noticed and promoted," said my baby-boomer parents. "You will master any skill with 10,000 hours of practice," said one of my mentors, highlighting a 1993 psychology paper popularized by Malcolm Gladwell's book "Outliers." (That's about 5 years of focused practice, by the way!) "Focus on your strengths, not your weaknesses," says Tom Rath in "Strength Finders." And "Follow your passion," supposedly taught to every Millennial (fyi, I'm not technically a Millennial).

All the sudden, I feel like an angst-filled, rebellious teen. Stop telling me what to do! Stop asking me so many questions! I don't know! Sorry, I digress.

Debate and Playing Nice

At any company where small scrum teams operate, the typical buzzwords are teamwork, collaboration, commitment, cross-functional, and self-managed. (Bleh!, buzzwords.) But what about tension, disagreement, conflict, and debate?
"What we need is collaboration where tension, disagreement, and conflict improve the value of the ideas, expose the risks inherent in the plan, and lead to enhanced trust among the participants. It’s time to change your mindset about conflict. Let go of the idea that all conflict is destructive, and embrace the idea that productive conflict creates value. If you think beyond the trite clich├ęs, it’s obvious: Collaborating is unnecessary if you agree on everything. Building on one another’s ideas only gets you incremental thinking. If you avoid disagreeing, you leave faulty assumptions unexposed."
Remember when I wrote about asking "Why?" in a previous post? Well, that's why you ask why, to solve the right problems, build better products, and nurture stronger teams. Debate is important, healthy, needed. Bring it!
Now, I'm not saying that you should go into all your standups, grooming sessions, and retrospectives ready for battle, ready to pounce on the first thing you disagree with. There's still a grace to introducing disagreement and starting a healthy debate on a topic.
After years of intensive analysis, Google discovered the key to good teamwork: being nice! And that involves the concept of “psychological safety,” a model of teamwork in which members have a shared belief that it is safe to take risks and share a range of ideas without the fear of being humiliated.
"Google’s data-driven approach ended up highlighting what leaders in the business world have known for a while; the best teams respect one another’s emotions and are mindful that all members should contribute to the conversation equally. It has less to do with who is in a team, and more with how a team’s members interact with one another."
Wait, I have to be nice to everybody I work with? Yes, you need to be respectful, empathetic, and start with "the benefit of the doubt" in mind.
Luckily, my colleagues engage in healthy debate while everybody plays nice. Which is important because, 'The Rise of AI Makes Emotional Intelligence More Important.'

Why and No

by Wes Royer

If you have young kids, you probably have lost patience in the number of times you hear them tell you "No!" or ask you "Why?" But child development professionals will tell you that the use of those two words are positive signs of your child's cognitive, language, and social development.
So why is it as adults and professionals, we so often skip asking why or don't feel like we can say no? And, as parents, we are quick to say things our parents said to us, such as, "Don't you tell me no!" or, "Stop asking why!"
Whether you are a product manager, product owner, business analyst, account manager, etc., asking why and saying no should be embraced as the norm. Yes, within reason. But delivering value to your customers is a top priority. And asking why and knowing when it's appropriate to say no are pieces of the value puzzle.
MVP = minimum viable product. This term has been around since at least 2001 and is a commonly over-used buzzword. At my previous workplace, I used MLP (minimum loveable product). Minimum does not mean the product doesn’t provide value to the customer. It means highest value feature(s) first. Solve the immediate or top problems first and get that value in front of the customer ASAP.
You'll spend 20% of your project solving for 80% of your users, and then spend the remaining 80% of the project trying to solve for the remaining 20% of your users. MVP or MLP addresses the 80% of your users first.
But you cannot define a successful MVP without asking why. Ask a stakeholder, "Why do you need that feature?" Even better, "Why do you think your users need that feature?" What value will said feature bring to the bottom line? How often do you think this feature will be used? What user persona and problem are we solving for, and why is this more valuable than others?
And then, if asking why doesn't net a true benefit to stakeholders and/or customers, then why would we build that feature? This is where saying no comes into play. But how do I come right out and say, "No?"
In discussing this topic with a colleague, she offered, "There are benefits to the client in asking questions and saying no. We, as a partner, know the business of building software and many of us know the industry pretty well. Being direct, asking questions, and declining to do certain things develops our partnership and increases the value of what we are delivering. The added benefit is it creates a long-term relationship that requires less from us to maintain, equaling higher margins and profitability."
And if you feel the word “why” puts others on the defensive, another colleague offered, “Why questions can put many people on the defense, especially if they are coming from a person in a position of power like a leader or manager. A couple of suggestions to get at the same thing are, ‘Tell me more,’ ‘How did you get to this idea?,’ or ‘What are you trying to solve for?’”
Have you heard of the Bill Murray technique for saying “Yes?” You should read the humorous article, but here is the basic premise: Replace a hard “No!” with, “I have an idea that will solve a couple issues,” or, “I think there is more immediate value in focusing on X instead.” Replace your saying No with the client by instead saying Yes to something else more valuable. Not always easy, but a brilliant win/win scenario!
In our fast-paced digital world, it's not easy remembering to ask why, and can be even harder to say no, regardless of whether the request is coming from a coworker, a client, or friend and family. But when why and no become a regular part of your vocabulary, trust me, you'll feel liberated because you and those around you will be focusing on the things that offer the most value. Isn't that what everybody wants?
I ask why a lot and am willing to say no (it's still hard to do!). I expect my colleagues to ask me why often. And if they don't like my answer and tell me no, I will understand.

Data driven problem solving

Basically, when somebody comes up to you and asks you to add an enhancement or change a feature, it's the product manager's job to use data (UI analytics, market trend analysis, revenue trends) to prioritize that feature against everything else in the backlog.

Everybody's ideas for changes and enhancements should acknowledged, respected, logged, given some thought, but data should be used to identify the problems that need to be solved first.

Many people's ideas are bred from emotion, personal want, or jump to solutions. Product managers are problem solvers. Identify problems first before offering and prioritizing solutions.