Product Management is a Mindset.
Set back and ask why.Curisoity about Product

Lean Approach
Dont overcommit before you validate.

Waterfall Approach
Make big, complex plans ahead of time.

Agile Methodology
A set of values to ensure a lean style of development

The Agile Manifesto
1.Individuals and interactions over processes and tools
2.working software over comprehensive documentation
3.customer collaboration over contract negotiation
4.responding to change over following a plan.

The biggest part of Scrum is that it says your work should be divided into chunks of time called sprints. The second major part of the Scrum framework is that you should have certain regular meetings with your team, like a stand up meeting, planning meetings, retrospective meetings, among others. The main benefit of using Scrum is that the time box work structure I mentioned allows you to have more accurate predictions of when something might be done in the future based on average work completed in past sprints. Estimating time needed for development is a tough thing to do and that average work completed metric they call velocity is a big help.

Kanban is a framework for implementing Agile except it’s not as strict as Scrum in terms of meetings and times. The key difference with Kanban is that it doesn’t use time box work like Scrum does and it doesn’t prescribe any particular types of meetings or rituals for you and your team. Instead, Kanban focuses on the theory that only a certain amount of items can be in progress at one time.

Product Manager
The role of product management has been around for a long time. Although the title may have changed in some industries it’s a job that entails being responsible for the ultimate success of a product or line of products. It’s a person that is market and customer facing who is regarded as the user expert.
A product manager is responsible for the success of a product and at the same time leading the team that does the work to make it a success

Product Owner
In the mid 90s when the SCRUM framework came around there was some new team centric processes introduced. To cover these and several other extra responsibilities the SCRUM creators came up with the role called product owner who acted more as a team facing version of a product manager that kept everything on track. In essence when the two roles exist together in a company the product manager is a more strategic position and the product owner is a more tactical one. However like I said these days it’s more rare to see a separation in these two roles. Most commonly you’ll see one person do both of these jobs and their title will just be product manager.

Project Manager
We already know that product managers are responsible for the success of the product but what does that even mean. Success is defined by meeting goals and metrics like improve conversion by 10% this year.So product managers need to reach a goal to achieve success but the way that they do it with their teams is not defined.One of the biggest parts of the job is figuring out the best way to reach the goal through agile development and testing.This makes a product manager the perfect role for figuring out how to optimize products where the best way forward is unknown and needs to be discovered continually.

Project Manager — Now on the other hand, what if you know exactly what you need to do? Imagine you’re building a skyscraper or a massively complex software project like an operating system. In this case everything is already clear, from the date it needs to be done to the building requirements, design and budget. This is a job for a project manager. Their definition of success isn’t meeting a metrics goal it’s to complete a set of unchanging requirements written out very clearly from the beginning. They lead the team to complete the work on time and on budget while accounting for any hiccups along the way So there we have it.

Stakelhoders — stakeholders, which is just a fancy term for people who have input into what you’re building. Examples of stakeholders are your users, executives, and other teams like legal, sales, and marketing.

Consumer PM — B2C PM -> As the name implies, these are the folks who build products for the everyday consumer out there.
Since the primary stakeholder for a consumer product manager is usually thousands of users in the general public, these PM roles are usually very focused on the creative side of things as well as vision.

Consumer PM ->
- Focus on creativity and vision
- Talk to users
- Test prototypes
- Analyze user data

Internal PM — These product managers and their teams are focused on building tools or systems for other people within their own organization, thus the name internal. Since their primary stakeholders, the users, are inside the organization, these PMs are typically more focused on execution and making their co-workers as productive as possible.
An example of an internal PM would be one that leads development on a feature that the customer support team can use to help users do something easy like reset their password.

B2B product manager role. — Commonly found working at Software as a Service or SaaS companies, these product managers lead development on products whose user is someone at another company. This role differs from the other two because it’s very common for companies to buy products they use through salespeople.

Consumer PM focuses on the external public users.
Internal ones focus on people within their own org.
B2B product managers focus on the end purchaser of their product through the sales team or the business users themselves.

Types of Teams:
- Platform Teams — Now let’s start with the idea of platform teams. Imagine you have two apps, one for iOS and one for Android. A platform team model would mean that there’s a separate team and thus a separate product manager for each platform. Many startup companies find themselves in this model as they grow, but there are big drawbacks. The primary issue is that you’re likely to have major inconsistencies in each platform since the teams and work streams are separated. If the iOS team finds a great trick for increasing engagement on their platform, it’s not guaranteed that the Android team will find out and develop the same thing on their side.

- Feature Teams — In the feature team model there’s a permanent team of a PM, designer, and engineers dedicated to a specific feature or function area of a given product across all platforms. That means that if a team is in charge of something, like say search, they’re working to optimize it on all of the platforms at the same time, while another team works on another area of the app in the exact same way. On the plus side this increases. On the plus side this increases consistency in your product, enables those teams to really become experts over time. But as you may have guessed, the downside is that this model generally requires more people to make it happen since you’ll need engineers for every platform type on each team, not to mention more designers and product managers.

Feature Teams:
- adding regular rotations so that instead of having permanent stations the teams rotate every so often to go work on a totally different feature area.A team working on search this month might be working in the chat system in six months. This helps everyone become familiar with all aspects of the product over time and bring a fresh perspective to things regularly. Facebook is known for using this model in their teams.
- Lastly, there’s another tweak sometimes referred to as squads. These are just feature teams that work on improvements to a product on a per-project basis. sometimes across a few different features at once. After their goal is achieved, they rotate off to a new project.But it’s likely that it’s based on achieving some definition of success through metrics established beforehand.

The vast majority of decently resourced software companies these days work in some form of a feature team model. Always consider your end product, company culture, and resources before deciding on which model is right for your organization.

Vision,intutuion and when data is not enough
Using Data
- Avalibale
- Accurate
- Optimization
If you want to make big strategic product changes, don’t make the mistake of thinking that a new direction has to be measurable, testable, or provable through data to make it worth exploring further. The data to prove it might not even be available to you or be able to be tracked. Secondly, the amount of time you spend testing or debating a new approach might take a little bit longer than actually giving it a shot, especially in more bureaucratic companies. Sometimes a great product sense and gut intuition is the most valuable tool in your kit as a product leader. It’s possible to create user behavior and demand for a product by simply building an outstanding product alone.
As a product person, you’re like someone building a house by hand. Data is but one tool in your toolbox and a very effective one when used appropriately. However, your experience, intuition, and talent are your hands that hold the tools that you choose. Keep in mind that famous quote, “If all you have is a hammer, everything looks like a nail.”

Working with stakeholders: Engineers

Working with Engineers:
- If something goes wrong, it’s your fault
- Futureproof everything
- Do work upfront
Tech debt is a term used to describe something within the code or technology that will have to be fixed at a later date as a result of not being done properly the first time. Let’s say that we’re building a new feature that accesses a database. We might use an existing database to save some time, but if it becomes popular enough, then it will eventually need its own database, necessitating a long and complicated switchover. Engineers hate tech debt because they’re the ones that have to deal with it, and many of the problems are caused by managers who rushed them during the initial build. Don’t be that person. Trust their advice the first time. Don’t treat engineers like an agency. What I mean by this is don’t work in a bubble without allowing your engineers to share their input.Don’t just hand over a set of completed requirements and expect them to code something up. Always give them the opportunity to provide feedback.

Working with stakeholders: Designers

Designers are first and foremost creative people. One major part of their job is to create a visual representation for the future of a project, not just as it stands now

Working with Designers
- Be clear about limitations
- Don’t outsource to your teammates
- Work as team
- Tackle problems first

Always discuss user problems first and solutions second. For example, don’t just tell them that we need to design for future X that does thing Y. That describes the solution without explaining the problem it’s designed to solve. Instead, explain the problem itself. In this case, it might be that the designer can help you come up with a better solution for the problem at hand than you can by yourself. Never forget that your job in a product role isn’t to be the solution finder on any given topic, but instead, to be a facilitator for the design and engineering experts to do their jobs the best they can.

Working with stakeholders: Executives and others
— Product managers often find themselves in the unique position of acting as a go-between with senior executives and CEOs on one side and creatives and programmers on the other. Your work will involve a huge amount of communication with executives and other team leads like those in sales, legal, marketing, and customer support.

Working with Executives:
— Be brief
— Show the impact
— Learn their style
— become familiar
— Share frequent updates

4 ways to be more effective at product management

being Effective
— Ask for feedback
— Understand people
— Be a news ponge
— Document

I take about 40 minutes every morning with my coffee to read any pertinent news on blogs, Twitter, Reddit, and most importantly, aggregation sites like Techmeme and Hacker News. Lastly, document like crazy

Hiring Product Managers
— Uncover their previous success
— Drill into their experience
— Discover their natural inclinations
— Assure they have a PM mindset

Really effective PMs should have a habit of questioning nearly everything, probing for more detail and thinking outside the box solutions. In an interview, you ask whether they think you should build a mobile app. The wrong answer here is a yes or no. The correct answer isn’t an immediate answer at all. Instead, I would look for them to ask for more details to better make their decision. Somethings I’d expect to hear in response are, what percentage of your traffic returns on a daily, weekly, and monthly basis? Or, what’s the percentage of traffic to mobile web, et cetera? When they do arrive at an answer, it’s okay if it’s not the correct one. What you do want to understand is their thought process around how they arrived at their answer
What they think, why they think that, and what information they could get that might impact their opinion?

Managing Product Managers
- Mentor
- Enable
- Establish clear guidelines
- Set Goals
- Lead them to correct strategies
Never micro manage your reports

Ensure your team is working on projects they are both passionate about and effective at.
A product manager with a design background will likely be more effective and happy working on consumer facing features with designers than they would be at optimizing a search algorithm with data scientists.

Roadmapping is an art,not a science

Making a Roadmap
- Layout deliverables — The first way to make a roadmap is the old way, and unfortunately, the most commonly requested by executives. This is when we lay out the things you’re going to work on and deliver from now to a year or more down the road. These are done in a quarterly format, in something like a Gantt chart or a spreadsheet. On the plus side, it gives the higher ups a nice document to look at, that comforts them to know which features will be launched when.The downside? Yep, you guessed it. It’s almost always completely inaccurate due to the nature of agile development

- Organize deliverables into categories — Organize your plan features and optimizations into three categories of when the work is happening on them. Now, Near Future and Far Future. This will satisfy the concerns of most stakeholders, illustrate your priorities and you can even still give vague monthly ranges to Now and Near Future, like one to two months and three to seven months.

- Set objectives and key results — This is the O-K-R Method, which stands for objectives and key results.Instead of showing what features will be worked on in certain time periods, an OKR roadmap shows which metrics goals will be worked on during those time periods.
Here’s an example. Instead of a roadmap that says, “Feature X will be done in Q3”, it says “In Q3, we’ll try to improve engagement by 10% “To do that, some features we’ll consider are X, Y and Z.To do that, some features we’ll consider are X, Y and Z.” This way, your priorities are clear, your executives get a hint of what concrete things may be coming up, and you’ve got flexibility to change what you develop based on test data, thus retaining agility.

The best roadmap approach is one that is clear, fits your culture, requires the least updating, and keeps all stakeholders as happy as possible.

The importance of customer journey KPIs
User Jouerney — Phases a user goes through before, during, and after the using a Product.

Let’s talk about how looking at the user journey can avoid these issues. Imagine you’re developing a new app and the new user signup rates are increasing. Sounds like you’re doing a great job, right? Well, not necessarily. A more thorough look may show that the retention rates are horrible. You can sign up all the users in the world, but if those users abandon the app as soon as they sign up, your effort is sorely misplaced. A solution to this problem is to track not only one metric, but a set of them within what’s called the user journey. This is just a fancy way of saying the phases a user goes through before, during, and after using a product. But which metrics make up the user journey exactly? Well, the answer is up to you, but, luckily, there are a few frameworks out there that can help you brainstorm.
The first one is a popular framework called the AARRR framework. AARRR is actually an acronym that stands for A, acquisition. How many potential users become aware of your product, such as seeing and downloading your app on the app store. A, activation. How many of these people actually become users, like creating an account? R for retention. How many come back regularly? So, people using the app every day. R for referral. How many refer others to the product? That is, how many tell their friends about it? And, lastly, R for revenue. How many users are making you money, or, say, buying your product? So, as you can see, going from signing up to being a paying customer is like a journey. This framework is pretty heavily focused on virality and growth, so, fortunately, there’s another one out there originally developed at Google called the HEART framework. HEART is yet another acronym that stands for phases of the user experience. H for happiness. How happy are your users? E for engagement. How frequently are they using your product on a short-term basis? A for adoption. How many users are you gaining over a period of time? R for retention. How many users come back to use it again over the long-term? And, finally, T for task success. How many users complete a task you deem to be important, like making a purchase or successfully finding something in a search? To put either of these frameworks in practice, make a table with each of these words in a row from top to bottom. In the right column, put a metric you can measure. If you don’t have a way to measure a particular phase, you know that you should focus on tracking that metric to get a complete picture. If all of this seems complex, don’t worry about it. Don’t stress out about adhering to these or any other framework strictly. They’re simply tools to help you decide on which metrics to track. The most important takeaway here is to never track one or two product metrics at a time. Instead, measure several that illustrate the user journey. This ensures your development efforts are correctly placed and is a great way to find out if a change in one place has an unintended effect in the other.

Types of companies -
- Consumer facing
- B2B
- Sales driven
- Ecommerce

Influencing without authority
- Be visible
- Build a reputation as an expert
- Be a problem solver
- Give credit where it’s due
- Be passionate

To be influential, you first have to be visible. If your colleagues don’t even know you, how can they trust you or listen to your ideas?Make sure you’re a familiar face and build your internal network. One simple way to do this is to follow that often repeated office advice: never eat lunch alone. If you see an unfamiliar face in the lunchroom, get to know them and make friends. Talk to people about what they’re working on, what their work-related problems are, and see if there’s any overlap between your work and theirs. The ability to put a name to a friendly face will help you establish a reputation around the office.

Setting vision as a product manager
So what exactly is a vision? Basically, it’s just a big picture you paint for your team about where your product or company is headed. Having a clear and consistent vision is absolutely vital to making sure everyone at the company makes decisions that move the product closer to the ultimate vision.A vision is just an idealistic opinion about how things will be in the future
In truth, it’s completely possible that a vision won’t become reality. It’s also likely to change every so often to fit external circumstances like competitor moves or technological advances. Even still, a vision should be vivid and exciting. If you’re making a product vision, you also need to make sure that a vision for your own product area will support the vision laid out by the executives.

Elements of a Complete vision
— Global Vision
— Product or company vision
— Goals
— Initiatives

A complete vision should have each of these items. First, a global vision. This is just an opinion on what the world, technology, and the industry will be like in three, five, 10, or even 20 years; go crazy. Then, product or company vision. This is how you want your product or company to fit into the world you described in that global vision. Then we have goals. Working backwards, these are the goals you need to hit over a period of time to make the vision possible. Then, initiatives. Backwards further, these are the things you’ll need to build or do in order to achieve those goals.

SpaceX Example
— Global Vision: land on Mars by 2030
— Company vision: First to accomplish
— Goals: Decrease cost by 10
— Initiatives: Resuable rocket engine

Being a PM in a sales-driven company
— get direct customer feedback
— Beware of tech debt
— Uderstand the difference between a user and a customer

There’s almost always a distinct difference between the user and the customer. The user is the person using the product, like say a marketing manager, and the customer is the person making the decision to purchase, like a VP of marketing.

The perfect product management tool
- understand how work is getting done
- ensure a software meets needs exactly
- Make a decision
- Decide on a process
- Educate everyone

The recipe for a productive meeting
- Invite appropriate stakeholders
- Create an agenda
- Start on time
- Create action items
An effective follow-up starts with a clear email or document assigning accountability to each stakeholder with clear and agreed upon timelines. Short, sweet, and effectiven

QA turned PM. With an intuition of QA and mindset of a Product Manager.