 I have never been a fan of using the word “strategy” or “strategic” because more than often they’re abused and misused by the most uninspired people in corporations – most of the time they mean “tactics”. As product management is still evolving as a key function on organizations, companies (especially those outside of the tech industry attempting to succeed at “digital transformations”) are struggling to clearly define the role in their organizations. Long time ago, PMs were often primarily responsible for technical project management and decisions about the product were typically led by sales or marketing or engineering. But today, as companies compete on product experience and the bar is already extremely high, PMs need to go beyond understanding technical issues or managing scope creep in order to decide what to build next and effectively align the company around their decisions. Product Managers need now to focus drawing out customer insights, learning about customer behavior through experimentation, defining long-term success, and inspiring non-product teams. Customer Insight Management User feedback is very important in order to build features that solve problems, and as such it is critical to go as deep as possible into user insights in order to go beyond surface-level feedback (“the product isn’t working”) to uncover the real actionable information that makes the product truly better (“the feature is fine but the customer doesn’t have the necessary knowledge to use it properly”). I have seen a lot of leaders (Refer to the hippo or rhino in the dangerous animals of product management here) who will push teams into building a fix right away or to build a new feature altogether without learning more and there’s a good chance they’ll push the teams to build the wrong thing. One thing that I have always suggested successfully is to build a good repository of customer insights in a single location, because insights always come into the business via many different channels like support tickers, email, slack, sales notes, and even social media. Without a central, searchable location, chances are many valuable insights will be missed and overlooked. Second, Product Managers need to know how to interview their customers (without offloading that responsibility to other teams such as “research”) – as an example, users rarely express the root cause of their problems when they give feedback. In fact, most of the time It takes multiple nested questioning techniques to drill down into the customer’s experience and find the exact source of a particular pain point. Personally I suggest to use the design thinking “five whys” technique. Experimentation and Prototyping I have seen teams forced into “velocity” making the horrible decision of moving straight from insights into rolling out features – and of course fail, as any feature can be designed in many different ways to solve the same problem while users will interact with some designs better than others. And very often, the most logical solution to a problem won’t always be the one that customers adopt, so the best way to figure this out is to experiment. There is already a school of thought and trend around a “behavioral product manager” function that blends data with psychology – understanding that humans have systematic irrationalities and as a result to not build products based on personas or ideal customer behavior, because there is always a difference between ideal customer behavior and actual customer behavior (I always tells my teams “there is a difference between what people say and what people do”). And as a result, prototypes are ideal because they’re clearly the best way to align specific features with customer behavior and find a solution and design that works well. I’ve always been a big fan of hi-res prototyping by product managers using tools such as Origami Studio or Figma because they offer usage data hooks and APIs which gives a lot of flexibility to the product manager to A/B test an hypothesis. Evangelizing for long-term success Unfortunately, and I know this is not very clear to many uninspired leaders in many industries, a product manager’s daily activities isn’t only to ensure that all the features that the team builds perform well and measuring the success of those features: Product managers guide a product towards a long-term goal and vision. So getting sucked by your leadership in constant reactive mode of giving all priorities and attention to shipping features is way too easy, so don’t: Think outcome instead of output, that’s where the real impact is. And as such, it is super important to define the larger objectives of the product, and, secondly, to visualize and map out how the features being build will support those objectives. And for those who have been exposed to the “press release backwards” methodologies (I’ve posted about it last year here) a strong word of caution: objectives can’t just be lofty statements that the team writes down somewhere and doesn’t think about again. To make sure progress is being made towards objectives, every feature request and every upcoming feature needs to be organized based on the objective it supports. By mapping out the relationship between the features the teams works with day-to-day and the big picture goals for the product, product managers will be able to stay focused and to resist the pull of building feature after feature without a unified sense of direction. Inspiring teams across the company I have discussed this previously here: it is critical for the success of the product that the entire team, from engineering to design, marketing, sales, and customer success feel excited about the features they’re building. The product manager plays a critical role in motivating all team members even though there are a lot of decisions that impact the product that they don’t own. As a result, this might sound a little bit corny but Being a persuasive product manager, then, boils down to getting everyone in your company to take pride in their contributions to the product and value the vision you have for it, even though it might not match what they want from it. Here, easy wins matter, such as sharing the product roadmap so that all stakeholders can see how things fit in the bigger picture. Let me know what you think here. My name's phil mora and I blog about the things I love fitness, hacking work, tech and anything holistic. Head of Product thinker, doer, designer, coder, leader
0 Comments
 Performance informs business decisions, KPIs drive actions: I was discussing with another startup founder this week (hint hint) on the importance of being data-driven in all decisions (I did write about this on medium a few years back). Key performance indicators (KPIs) are milestones on the road to success and monitoring them will help product-driven entrepreneurs identify progress towards their goals (of world domination) – and as such, KPIs should be chosen and monitored based on a startup’s specific and unique business goals. But with that in mind, I was thinking I would write a quick reminder note on the most common funnel-driven KPIs in e-commerce. Discovery metrics: Help Measure the activities that create awareness and discovery
Acquisition metrics There are many, many metrics in this phase of the funnel, so we’ll only focus on a few.
Conversion metrics Measure the performance in converting from a store visitor to a paying customer, adding products to their shopping cart and actually checking out.
Retention metrics. Acquiring a new customer is anywhere from 5 to 25 times more expensive than retaining an existing one. Retention-focused metrics drastically benefit from good customer service, loyalty programs, repeat purchase campaigns, and a true investment in customer satisfaction.
5. Advocacy metrics Advocates are a company’s goldmine, they’re the ones who deserve the white glove treatment. These metrics will help a company measure the efforts taken to show them the Company cares.
Let me know what you think here. My name's phil mora and I blog about the things I love fitness, hacking work, tech and anything holistic. Head of Product thinker, doer, designer, coder, leader  A few weeks back I was talking to a startup founder and we were discussing product-market fit … This is actually a really good question in the context of Agriculture: a very slow, cyclical, highly commoditized and culturally entrenched industry – almost backwards by high-tech industry standards. And as such, I’ve been ideating on trying to find a good definition of a starting point for product-market fit in Ag and how, as an early stage startup and as a product manager, we should tackle the answer. More generally, product managers will always find it hard to figure out what features and product initiatives to prioritize amongst so many competing priorities and stakeholder demands (I have talked about this here!) Made popular by Marc Andreesen in the 2000s, product market fit at the time was the “only thing that matters” or the exact moment when a startup successfully finds itself in “a good market with a product that can satisfy that market”. In the B2C world, this is iPod and the fitness crowd in 2003 or Netflix and DVDs in the early 2000s. But how does this pan out in the B2B world of AgTech? Since there is a lot of product/market fit literature all over the internet, here’s a sampler of what I gathered with a quick google search and that I find the most relevant:
A. Product/market fit is when you build something that people want I will have a more detailed note about this particular definition very soon – it’s a great update from the initial Marc Andreesen definition by Paul Graham (Y-Combinator). Essentially, it stems from the accurate observation that most founders build things nobody wants. And the reason is that they think about startup ideas, not products but sound plausible enough to fool them into working on them. Graham goes on that when launching a startup business, there should already be some people who urgently need the product, and not just the idea of a potential benefit of using it. So the only question that matters is “who wants this right now?” – And as such as an entrepreneur as well as product manager, instead of (most often than not without evil) forcing your views on users, always ask yourself who wants what you’re building so much that they’ll use it even if it’s a crappy buggy first iteration MVP? B. Product/Market fit is when you have the right solution to a problem that’s worth solving The lean startup literature refines the two previous suggestions further by breaking up this startup lifecycle into three stages:
C. Product/market fit is when users love your product so much they tell other people to use it This is my favorite because this is Porter early definition of Product/Market fit in the 1990s, way before “software was eating the world”: “When people understand and use your product enough to recognize it’s value that’s a huge win. But when they begin to share their positive experience with others, when you can replicate the experience with every new user who your existing users tell, then you have product-market fit on your hands. And when this occurs something magical happens. All of a sudden your customers become your salespeople.” Simply put, product market fit is having enough users that love your product so much they spontaneously tell other people to use it … in other words, as a product manager you build a strong viral base of advocates for your product. As an example, chances are that the first time you used Slack somebody in your friends circle invited you to use it – you didn’t click on an ad online, right? By doing so you will also avoid the trappings of targeting a growth goal first and probably fool yourself until someone (like me) digs into your user retention numbers! (See my note on growth product management pitfalls here.)  In conclusion, for product managers as well as startup entrepreneurs, and also in the context of Ag Tech startup this does apply super well, which is the reason why I thought about writing this in the first place, it’s important to separate product/market fit from problem/solution fit and more specifically, in order to estimate your true potential customer base, you will need to make sure you measure the true desire for your product, not just for a solution. If not you’ll most likely end up with a product/market fit false positive. Further, always thrive to find a high or extreme degree of product/market fit or set yourself up for a giant, and often times, super costly, world of painful disappointment. Let me know what you think here. My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. Head of Product thinker, doer, designer, coder, leader  Last month I wrote about the essential soft skills that product managers must possess to be effective in driving the product development process, and I came across this super clever story from Product Board – it really resonated with me while turning around the digital division at Nutrien over the past two years so i thought I would share. Picture this. You are a forward-thinking product manager with a clear product vision, a value-driven prioritization framework, and a context-rich roadmap. You make it a point to listen to customer needs and incorporate feedback from many different perspectives. Yet, throughout the product management process, stakeholders come to the table with unvalidated requests. 'This must be built," they insist, "and right away." Introducing the dangerous animals of product management: stakeholders and situations that-if left untamed-can get in the way of your carefully planned product vision and strategy. The dangerous animals of product management WoLF (Working on Latest Fire) When you neglect technical debt and issues like security and product functionality to focus solely on new features, you can end up with wildfires that require your immediate and complete attention. The WoLF's cycle of reactivity demands all your resources, seriously hindering productivity and innovation. RHiNO (Really High-value New Opportunity) You can recognize a RHiNO by their call, "If we just had feature X, we'd be able to make this sale/land this particular customer." When you address the RHiNO's one-off requests too often, you are focusing on solutions rather than solving real problems for a broad range of customers. HiPPO (Highest Paid Person's Opinion) It can be tempting to give in to HiPPOs (founders, CEOs, or other leaders). But letting HiPPOs make all the decisions can lead to products or features that haven't been validated. This can kill morale and introduce risk, making way for what product leader John Cutler calls a "Feature Factory''. ZEbRA (Zero Evidence But Really Arrogant) ZEbRAs think they know it all, but rely on their gut rather than any actual evidence. ZEbRAs might luck out and occasionally get things right-but not nearly as often as when you take the time to test assumptions and gather data to support your decisions. Seagull Manager Seagull Managers tend to be a little bit removed from your day-to-day work. However, they occasionally swoop in, cause a ruckus, then swoop out again, leaving the team to clean up the mess. Their intentions are good, but they aren't always aware of the long-term effects of their proposed solutions. Download Product Board’s E-book Here. (05/11/2020) Let me know what you think here. My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. Head of Product thinker, doer, designer, coder, leader |
head of product in colorado. travel 🚀 work 🌵 food 🍔 rocky mountains, tech and dogs 🐾
Categories
All
|
RSS Feed