Tag: #productmanagement

  • Working with Compliance as a Product Manager: A Practical Guide

    Working with Compliance as a Product Manager: A Practical Guide

    Let’s talk about working with compliance as a Product Manager. Whether you are a Product Manager or you aspire to be one, you will come across the world of compliance and risk management. This is especially important in industries or domains that require heavy regulation.

    For example, financial services, healthcare, medicine, food etc. are all heavily regulated.

    While you are not expected to be an expert in compliance and risk management, you are expected to understand what this means for the product and for the business.

    How does this really work? Let’s begin by first understanding the levels of compliance.

    Number 1: Company-level compliance

    At the very center, you will have compliance rules at the company level. There are certain guidelines that the company abides by and defines as standards to adhere to. These become your compliance rules.

    For example, “We do not want to sell our products to people under 18 years of age.” That’s a compliance guideline set by the company.

    Another example might be: “We do not wish to sell in a certain country or continent.” This means when your user tries to access your product from that country, they need to be blocked or restricted.

    Number 2: Country-level compliance

    The next level is compliance guidelines applicable in the country you are based in. For certain industries, each country sets up a bunch of rules and regulations for the safety and benefit of their citizens.

    Let’s say you are headquartered in USA and you wish to sell medicines online. USA might have a regulation that requires certain medicines to be FDA-approved before selling online. It is your responsibility to ensure that your online store cannot sell those specific medicines unless they’re FDA-approved.

    Let’s take another example. Imagine you’re in financial services or fintech sector in India. One of the rules for international transfers might be: “You cannot transfer more than $10,000 in a single payment.” If your product offers international payment transfers feature then you have to ensure that people don’t transfer more than $10,000 in a single payment.

    Number 3: Compliance in country of operations

    Suppose you are based in Singapore and headquartered there, but your products are being sold in the USA then you must also comply with USA regulations.

    Being compliant in Singapore alone is not sufficient anymore. You must be compliant in your home/base country and in every country you sell your product in.

    This is where many junior PMs make a mistake. I made a mistake too. I assumed that our product was ready for the global expansion only to realise later that I needed to be compliant in each new country that we expand to.

    Number 4: Global or Domain-specific compliance

    Finally, there may be compliance rules specific to your product’s domain or applicable globally. For example, The OFAC (Office of Foreign Assets Control) in the U.S. may blacklist certain countries or individuals. The OFAC is a financial intelligence and enforcement agency of the United States Treasury Department. While it is meant for the USA, their list of sanctioned people and countries is widely used by the Fintech companies.

    Why is this important? International payment transfers are very risky. People send money for all sorts of wrong reasons. While there are multiple ways to prevent fraud, one of the ways to detect is to validate sender and receiver details. Suppose the receiver is a criminal organisation and it is part of the OFAC sanctioned list then payment apps block such payments.

    Similar to OFAC, there will be other global bodies that may be relevant for your product’s sector; and you need to be aware of those.

    Why do we need Compliance team?

    Most companies will have Compliance team. They have titles like “Compliance Officer”, “Risk Analyst”, “Compliance Manager”, “Fraud & Risk Analyst” etc. People with these titles come with vast experience of the domain knowledge. If you are part of a company that does not have a dedicated Compliance Team then you should talk to your managers or core team and establish the key decision-maker.

    Here are 3 reasons for having a dedicated team:

    1. Awareness of implications for non-compliance: This is by far the most important reason. A company should be aware of all possible implications for not complying with rules and regulations. The implication can be as small as minor fee or as big as a multi-million dollar court case. It is the team’s responsibility to understand and break down these implications and ensure that the product is compliant. They work with the Legal team to ensure that the company’s interests are protected at all times.
    2. Keeping up with the authorities: Regulatory authorities continuously make changes to the policies and issue new guidelines. This team knows the right place to get the latest updates and make sure they don’t miss out on critical updates.
    3. Understanding the legalese: If you have ever seen a guideline or a document issued by any regulatory body, you know how incomprehensible it can get. With their experience in reading these complex documents, they are able to decode it much faster.

    You might think this all sounds very trivial. But in reality, it is not nice to get police complaints and legal notices.

    What is Product Manager’s role if Compliance Team exists?

    Compliance team’s focus is to protect company’s interests at all costs. This means at times, Compliance team will seem like a blocker. They would want to impose all types of restrictions. While some requirements are non-negotiable deliverables, some other requirements might be negotiable. Let me explain what I mean by negotiable with an example.

    Suppose you are in Fintech and your app allows people to send money from their account to any person anywhere in the world. Now, imagine a regulation that says, one person in Country A cannot send more than $10,000 to another person in Country B in a month.

    Your compliance team could say, “let’s block all transactions between Country A and Country B on our app.” This is the most restrictive interpretation of the rule. If you read the rule again, you will understand that the limitation is on the total amount a person can send in a month. This type of requirement is negotiable and open to discussion.

    An example of non-negotiable requirement would be “government has ordered all companies to stop the transactions between Country A and Country B”. You have to simply deliver on this.

    Since a Product Manager is responsible for the success of their product, you often have to find the right balance between being compliant and harming the user experience.

    Therefore, a Product Manager is required to advocate for the users while the Compliance team advocates for the company.

    Framework to approach compliance requirements

    Let’s do a thought experiment. Imagine you’re now part of a product that has to be compliant whenever you make a new feature release. How do you proceed?

    If you are absolutely new to the product you might have to do some prep work.

    • Identify the Compliance team or member responsible for final decision-making.
    • Identify the relevant regulatory bodies for your product. Read more about them and their frequency of issuing new policies.
    • Understand the existing rules and why they exist.
    • Go through the current user’s journey and make a map of it. Try to break down the journey in smaller chunks and then create detailed map of that user’s journey.
    • Ensure there is proper documentation of all the existing rules and validations that make your product compliant.

    By doing the above steps, you become more knowledgeable and your opinions will have depth during the meetings. If you skip these steps you are more likely to play catch-up game during important discussions.

    When dealing with new feature request from Compliance team

    You begin the Product Discovery phase and document everything:

    • What are the exact rules issued by the regulatory body?
    • What changes are expected in the product?
    • How does the current user experience look like?
    • What will change in terms of UI?
    • How should we communicate with the users and other teams?

    Tip: The key here is to be concise and precise when documenting the first draft.

    By the end of your short discovery, you will have clear idea of what changes are expected.

    Next is, Prioritization. It is very likely that you are swamped with work because you might have committed to a roadmap already. Before you open discussions with other stakeholders you need to know following things:

    • Is there any deadline set by the regulatory bodies? Is that deadline negotiable?
    • Do we have any legal implications for not delivering on this requirement?
    • Does it line up with our current company strategy? Or are we doing this for the sake of doing it?
    • Other than being compliant, are there other potential benefits to be unlocked, e.g. can we expand to another market easily if we do this now?

    Tip: It is very tempting to neglect requests from Compliance team but ignoring them can have dire consequences for your product. As a PM you should be aware of all risks.

    Assume you have the highest priority for this feature request, you then begin Design and Development phase. You can follow whatever process you have when it comes to design and development but ensure the following:

    • Share the first drafts of your design for early feedback.
    • Once you have final designs, share them with other stakeholders that might get impacted by the upcoming changes. For example, if you are making a change that has positive impact on business strategy then inform Business team so that they can prepare their pitches accordingly. If the change adds more work to Operations team, then show them the designs and help them prepare ahead of the release.
    • During this phase, keep an active line of communication with the Compliance team. They have to be aware of delays.
    • Give clarity on deadlines and expected end result to your Development team. Inform them about the implications of non-compliance.

    Tip: Design and Development is highly collaborative phase because during development you will encounter new blockers. As a PM, you should facilitate elimination of these blockers.

    Next comes, Testing phase. In my experience, getting your compliance team to test the features before release is very useful. It depends on the criticality of the feature and the availability of the team. Following things are important to do:

    • Prepare a short demo video and share with the team before you release to production.
    • Be flexible for the last minute changes to the feature.
    • You might get a list of improvements soon after the release, these should be documented well.
    • Document the potential impact on other teams and communicate that ahead of time.
    • Keep your legal team updated as well.

    Tip: When releasing critical changes, test the product yourself.

    Don’t skip Post-release monitoring. Most people move on to another feature. Here is what you need to be aware of:

    • Add event tracking wherever possible. This will help you create dashboard in analytics tool later.
    • Create reports and add them to your regular review meetings. This way, you can keep track of the feature performance.

    Final words

    Working with Compliance team might make you feel less autonomous but that is the reality of working in regulated industries. Don’t seek full autonomy and don’t work in silo.

    Compliance team will continue to advocate for the company and Product Manager should continue to advocate for the users. This is the balance you strike as a Product Manager.

  • Why Amazon’s Kindle is More Than a Device: It’s part of ecosystem

    Why Amazon’s Kindle is More Than a Device: It’s part of ecosystem

    In 2007, Amazon’s Kindle device sold out within few hours of its launch. Since then they have sold millions of devices. But why did Amazon start selling an e-reading device? Especially, they sold those devices at no profit. In 2012, Forbes reported that Jeff Bezos confirmed “we sell the hardware at our cost, so it is break-even on the hardware” in an interview with BBC.

    If it is not about the hardware then what is it about? You guessed it right, it is not just about the hardware, it is the ecosystem at play.

    Few years ago, I bought a basic Kindle. I am not an avid reader but I do like to carry books on vacation. With Kindle, I could carry more than one book everywhere I go. Ultimately, it became a habit to read on Kindle than to buy physical copies. Next thing I know I am buying e-books off of Amazon, loading on my Kindle and reading them there. They even have free books for Amazon Prime subscribers, discounts for Kindle editions. I am locked in fully!

    This is an incredible way of achieving retention of the customer through multiple products. We will come to that, but let’s go back a little.

    Kindle’s history: technology and design

    It was first released in Nov, 19 2007. By this time Amazon was already 12 years into the business. There is a very detailed article on its history and how it came to life on Amazon’s site. I recommend you check it out. Amazon’s own research lab, Lab126, developed the Kindle. The device was the result of four years of intensive research and testing.

    The technology

    Kindle uses the E-Ink technology for their devices. One of the crucial features of this technology is its paper-like display. There was nothing revolutionary about the E-ink technology itself. It existed since 1997, though it was popularised by Amazon Kindle. The E-ink technology has manifold applications but the biggest by far was the e-reader.

    Additionally, technology for storing large amounts of data in smaller memory spaces was rapidly advancing. This meant, storing text in computer is very cheap in terms of memory usage. You can see how .doc file takes 5KB but an image file .png can be much larger often 5MB or more. It was only matter of time, when kids would start doing their assignments on laptop, college students researching on internet instead of libraries and working people reading online more than hardcopies.

    For Kindle, it meant you can carry hundreds of digital books with you in a 174g device.

    Now, as a Product Manager, I take away couple of things from this:

    Instead of looking for new solutions and waiting for new technologies to arrive, find ways to solve customer’s problems with existing solutions. It makes you focus more on the problem and solve the right ones. Hard to do but worth doing.

    You could not come up with such a product in 1980s because we did not have that technology at all. You can only continuously research and iterate on products but understand that you may have constraints on the existing solutions available at that time.

    The Design

    A very important aspect for such devices should be the comfort of reading. If you are going to spend 2 hours reading, you cannot afford to strain your eyes. While E-ink technology provided paper-like display, there were other design considerations as well.

    One such feature is changing fonts and size of the text! They even got their own font called, Bookerly. You cannot do that with physical books. Your reading experience is determined by the Publisher who chose the fonts and size for you.

    For the visually impaired, there is an option to read out the text. Their blog covers more on this topic of Accessibility and Inclusion.

    Kindle Basic device’s design is very intuitive and minimal. Their recent versions, however, are loaded with features.

    Kindle does claim to have good design for form factor but based on my personal experience, I think it can be better. I cannot hold kindle for long periods of time. By the way, I experience same problem with books. Ergonomics should get better for such devices.

    However, the first version of Kindle device was nothing like its current version, they had to completely change their design. You can read this post by Josh Hrala on how Kindle has evolved over time in design.

    You have to get the basic requirements right when designing new products. While you can quickly iterate and ship refined versions, it cannot fail on the core value proposition. In case of Kindle, the value proposition was to read a physical book on a digital device in the most accessible way.

    Scope the minimum deliverable but consider usability and accessibility for the bare minimum features in your product.

    Having the right technology and the right design does not always guarantee success. You need distribution. For Amazon, it was not a challenge. Amazon had books and users. They needed to build the connector; a platform for digital reading era.

    Platform for Readers, Writers and Publishers

    Until Kindle’s launch, Amazon had physical book sellers on their marketplace. They needed to create supply for the digital books.

    The platform

    Amazon allowed authors to directly publish their e-books. This created a marketplace for authors and readers and saw some pretty nice growth too. TechCrunch article states, “Between 2010 and 2015 alone, the number of ISBN registered titles jumped 375 percent, from 152,978 to 727,125. Amazon’s CreateSpace accounts for the largest share of that growth.”

    In a traditional setup, small-time authors would have to wait for their publishers to approve and agree to print. Publisher’s credibility and distribution could make or break the success of the book. By directly selling to consumers, less renowned authors could publish directly. This unlocked an incredible opportunity.

    On the consumer side, they were locked in by the Kindle device purchase already. Amazon can now offer free books for Prime subscribers, or discounts on Kindle edition.

    Although Amazon offers enormous platform to the authors, it did not really eliminate all the challenges of traditional model.

    Challenges of the platform

    Amazon requires exclusivity from its Kindle Direct Publishing (KDP) Select authors, meaning they can only sell their books on the Kindle Store, and not on any other digital bookstores, or even on their own websites.

    As per their article Amazon charges royalty of 35% or 70% depending on territories the books are sold in. This is not very different from what traditional publishers would do.

    Authors have to work hard to promote themselves and attract new readers in a crowded marketplace because suddenly, everyone has option to publish.

    It is hard to know how Amazon team plans to handle such challenges but it certainly makes me think more. In a marketplace product, the balance between supply and demand has to be healthy enough for it to sustain. What happens if authors are unhappy? What happens when a lot of authors publish directly but there are no e-book sales? These are not easy problems, companies spend millions on research to handle such challenges.

    Short term success is good but it is good to have an idea about the potential challenges that could arises in the future.

    The ecosystem

    I mentioned in the beginning that I was locked in the Amazon’s ecosystem.

    The ecosystem is basically this, for every purchase of a product there is an auxiliary product or a service from the same company.

    No matter which product you buy first, you can buy related product from the same company. If you buy Kindle device first, then you can buy e-books from Amazon. If you buy e-books, you might be tempted to buy Kindle and so on.

    E-reading device sellers like Rakuten and Kobo are attempting build an ecosystem too.

    When I first saw Amazon selling Kindle device, I thought “Why is Amazon getting into this hardware business?” This is a Product Strategy question asked in many interviews for Product Manager role. “Should Company A expand into category X?” or “Should company B launch this new product?” However, after seeing the way they grew the product, selling hardware was not the main goal, it was to create an ecosystem for the user.

    I have observed this in Fintech companies that often build a baseline infrastructure first, get the customer locked in on the core product and then use this customer base to distribute new products. In India, Cred started as an app to remind you to pay credit card bills. Stripe in USA and Razorpay in India started as payment gateways. If you go to their websites now, you will see lot of other products unrelated to their core product.

    Ecosystem in your context may not mean launching new products all the time. Think of micro-ecosystems of intertwined usecases that your users may not have explored yet. If you notice that a certain feature is not adopted organically, think of new usecases and how it can solve other problems that user may not be aware of. Think of ecosystem and keeping the user in that ecosystem.

    As a Product Manager, you often have to step outside of the Jira board 😉 to think of ecosystem at play.

    Final words

    If you made it this far here is a fun fact about Amazon Lab126, they named it after their logo, 1 for A and 26 for Z.

    Let me leave you with some takeaways:

    • Think of your product features as tiny ecosystem of its own.
    • Keep your user in the ecosystem of your product.
    • Leverage existing solutions and technologies before jumping to creating new ones.
    • You cannot hack product’s quality. Decide on minimal scope but deliver the best you can.
    • Always evolve, don’t let the product go stale.
    • Think about the product’s distribution and marketing strategies while you execute.
    • Acknowledge the fact that a product’s success is a combination of its quality + market forces + timing.

  • Writing effective Product Release updates to your team

    Writing effective Product Release updates to your team

    Before transitioning into Product Management, I led a small team of Customer Success Managers. At our company, the Product Manager would send updates when new features and improvements were released. I’d read these emails to identify what was important for my team and our customers. The emails were usually clear.

    At that time, I focussed on just three key questions: What was released? Is this relevant for me or my team If relevant, how does it benefit our work? Any information beyond these questions wasn’t particularly useful for my role.

    This context is important because despite knowing the needs of the team, I still struggled to share product update emails that were helpful.

    I got very excited about features and I wanted to share every tiny detail with the team. I used to write lengthy release update emails. My good friend and ex-manager once told me, “Your CEO (or team) doesn’t have time to read novels”(referring to my long emails). In any other setting, this might sound harsh, but coming from a friend, I asked how I could improve. His suggestion was simple: be specific and concise. I tried to do exactly that.

    I adopted different formats for different features. For example, suppose you launched something really big, which is worthy of a blog post or even a PR article, you might want to plan that very differently. By the way, this article won’t cover it. Let’s be real, on a regular basis, you are probably doing bug fixes, product improvements and fixing technical debts. How do you then make it easy for yourself as well as easy for team to understand?

    I am sharing a template that I have used regularly.

    Now, let’s see how it will work realistically. We will take 2 examples for an imaginary order and catalog management product meant for Sellers of an e-commerce website.

    Example 1: New feature in the product, solves a big pain point for the customers.

    Example 2: Improvement to an existing feature that solves major problem for the internal Finance Operations team.

    Finally, just because I suggested a template does not mean it’s the right way or the only way. Come up with your own template but keep the basics in mind — No one needs to read a novel and yet, everyone needs to know meaningful changes in the product release. Try to make it concise.

  • How to approach Pricing Strategy for Marketplace as a Product Manager

    How to approach Pricing Strategy for Marketplace as a Product Manager

    “Why should I worry about the pricing strategy?” I asked my manager during a conversation.

    A bit of a story.

    I had taken up the ownership of a newly launched product. While we had basic pricing model in place, we had to re-evaluate our pricing strategy for new market launches. My manager asked me to come up with a proposal. At first, I resisted because I always assumed it was someone else’s job. After a long conversation with my manager, in which he explained why should a Product Manager think about the pricing strategy. You are the best person to understand core offerings of the product and the customer problems it solves. Therefore, devising a pricing strategy or ability to propose a pricing strategy is very much part of the job.

    That was my cue to start learning all about the pricing strategies and monetisation models. I bought the book Monetising Innovation by Madhavan Ramanujam and Georg Tacke. I watched countless videos on this topic from Y Combinator and other channels. I scouted the internet for any blog from startup founders and CPOs who had done this before. I was curious about both failure and success stories. I particularly remember an excerpt from Rahul Vohra’s interview. Link

    While I could not contribute to the pricing strategy at my previous company, I got a chance to work on a case study during my interview with one startup in Amsterdam.

    How to approach Pricing Strategy for Marketplace

    In this blog, I am laying out my framework and the approach I took. I am not aiming to provide exact answers because the assumptions and hypotheses may be different depending upon the context.

    Disclaimer: I cannot disclose the name of the company, so let’s call it Narnia.

    Here is the case:

    Narnia is a marketplace for buyers and sellers of agricultural goods. It is a new platform and has commitment from few customers to use it in the beta mode. Narnia wants to start with one or 2 products initially and then expand in different categories. Devise a monetisation model with hypotheses and validations. Monetisation model should include 1) Who to charge and 2) How to charge (pricing model).

    Here is what I would do:

    → Understand the market and the players

    → Understand the core value proposition of the platform

    → Describe the pricing strategy and the model

    → State the hypotheses and validation methods

    Understand the market and the players

    Since we know this is a marketplace for sellers and buyers of the agricultural goods, let’s start with them. Find out more about them.

    1. Who are these sellers?
      1. What is the ideal seller profile?
      2. What do they sell and how often do they sell?
      3. Where are these sellers based and where do they do business?
      4. What value is their current network providing them?
      5. What are their challenges in the business?
      6. Are they facing difficulties in expansion?
      7. Do they use any software tools to improve their process?
    2. Who are these buyers?
      1. What is the ideal buyer profile?
      2. What do they buy and how often do they buy?
      3. How do they buy goods today?
      4. What is the % distribution of pure buyers vs buyers + sellers?
      5. What are the challenges they face in procuring the goods?
      6. What challenges do they have when it comes to pricing of the goods?
      7. Do they use any tools to make buying decision and/or improve their process?
      8. Do they wish to buy from new sellers in different regions?
    3. Know more about the market itself
      1. How big is the market and what is the potential?
      2. What are the growth opportunities?
      3. Are there opportunities to expand in category or geography or something else?

    During this initial discovery phase, you may need data from both primary and secondary sources. This means if you have access to the sellers and buyers, talk to them! Else you can rely on readily available data from companies who may have done this research before.

    Understand the core value proposition of the platform

    1. Ask this “What core need of these sellers and buyers is the platform satisfying?”
    2. Identify the journey of the seller and the buyer. Put a pin on a potential opportunity as you do this.
    3. Does the platform have competitors? (If yes, just note them as threats. This is not an issue but it is good to be aware of).
      1. Are there other platforms with exact same solution?
        1. If yes, what do they offers?
        2. If no, why has anyone not done this before? Is that a risk to be aware of?
    4. If the product is already built, then how does the flow look like? If it is not built then draw out the ideal journey of the customer on the platform on a whiteboard.
    5. What part of the product the customer cannot live without? Knowing this will help the team focus on the right things.
    6. If this platform did not exist, what were their current alternatives? Do they use only their existing network and nothing else?

    Describe the pricing strategy and the model

    This is where you will put your knowledge from the product discovery phase to use. By now, you would have identified the customer’s problems, platform’s value proposition and the growth opportunities.

    It is time to propose!

    Option 1: You could say, we should “Charge the Seller” {Who to charge?} a “% commission on each transaction.” {How to charge}

    OR

    Option 2: You could also say, we should “Charge the Seller and the Buyer” a “% commission on each transaction.” {How to charge}

    This is not the only way to do pricing but whatever you choose to propose should be backed up with hypotheses. This brings me to the next section.

    State the hypotheses and validation methods

    Let’s take Option 1 → Seller is charged % commission per completed transaction.

    Following are my hypotheses:

    Why charge the Sellers?

    • Sellers find value in the marketplace and are able to sell goods at a better price because of data-driven insights and recommendations of Narnia.
    • Sellers are able to discover new demand and have the potential to expand their business to new regions.

    Why not charge Buyers?

    • Driving demand on the marketplace is crucial for initial phase to get the wheel running, and charging buyer would create an entry barrier.
    • Buyer’s core need is to look for the cheapest and most valuable product versus seller’s core need is to get rid of the supply; unsold supply is often costly to maintain.
    • Charging buyers will be difficult to scale because it needs huge volume of buyers to make money.

    Why this pricing model?

    • Narnia can scale their profits with Seller’s transactions growth.
    • Sellers will have a lower barrier to entry because of no prior commitment to pay.
    • Sellers are incentivised to engage with the platform before committing to pay; e.g. listing supply.

    Other model:

    • We could explore Subscription or fixed cost based model. However, I feel it will limit the potential of Narnia in earning more despite the Seller’s transaction growth.

    If you think about it, successful marketplaces like Amazon often charge the Seller on the platform and not the buyer. However, there are marketplaces that charge both seller and the buyer.

    Now for each of these hypotheses, I added validations. Validations had quantitative and qualitative methods.

    Think about it. You suggested that we should charge the seller and not the buyer. Which performance indicators can be monitored to determine whether the pricing strategy works or not.

    Here is an example:

    Hypothesis: Sellers find value in the marketplace and are able to sell goods at a better price.

    Indicators: Increase in new and repeat transactions, Able to sell at better price.

    Validation

    Quantitative data:

    a) Analyse the transactions and find the delta between the listed price, bidding price, Narnia recommended price and actual selling price of the goods. The % difference should indicate if sellers got more or less price for goods than expected.

    b) Track growth in new and repeat transactions for each seller. Ideally, there should be upward trend.

    Qualitative data:

    Gather subjective inputs as much as possible by interviewing every customer and ask if they find valuable to be on the marketplace and what more do they expect.

    I had more hypotheses and validations which I have not purposely listed in this blog else it will be too big. You get the picture.

    Document the threats and risks to your model

    1. In which scenario is the pricing model likely to fail?
    2. What can cause the drop in transactions?
    3. Will customers prefer another pricing model? Do we have feedback from the customers to make us think in entirely different direction?
    4. Is the pricing strategy not aligned with the business strategy?

    An example of one such risk: Commission model will make money only when there are substantial number of transactions, Narnia may make money only in the long run, not immediately.

    It is hard to say if this strategy will work or not. Much of Product Manager’s work is dependent on the company and its context. I am currently researching on ways to test my pricing strategy framework and do it myself. Your ideas are welcome.