Top to bottom

As 2022 drawers to a close, I've been thinking back on my career to date on some of the businesses i've worked in, as well as some that I've started myself. Specifically, how they organise themselves, and where the product function within that fits in.

First off, a couple of statements that some might agree with, others, not.

  • Product is the only department within the business that can 10X your valuation. While you can always hire more sales people and perfect your marketing strategy, these in my experience can, at most, extract another 20 to 30% revenue.

  • All successful product teams are underpinned by, a strong, competent and enthusiastic development team and a business, that is structured effectively for growth.

It is the structure that I've been reflecting on, because without it, no number of competent professionals can help you get you heading in the right direction toward growth.

Disclaimer : I do not hold an MBA and, furthermore, like many things in life and business, there are many ways to approach the task at hand. To that end, the below is simply a reflection of my experience and is by no means the only way to accomplish some of these objectives. With that in mind ……

Starting from the top

Step 1 : Company Vision

The companies vision is a statement that sets out why it exists. You can see a list of mission statements from well-known brands, here (some are significantly better and more inspiring than others)

We can take Amazon as an example in the below.

Vision Statement : To be Earth's most customer-centric company, where customers can find and discover anything they might want to buy online, and endeavours to offer its customers the lowest possible prices.

This vision statement should be one that everyone in the business understands, and knows. It should be the founding principle behind the values, the business promotes and staff are encouraged to embody.

This vision statement, can be adjusted as companies grow and need to pivot into new areas, however, when those pivots occur, this vision statement is re-drafted and communicated relentlessly.

Step 2 : Business Strategy

Establishing the business strategy is undertaken by the founder and the top team, and typically makes use of a diaspora of templates and communication tools that illustrate the areas, the business must push into to realise the vision statement.

Some examples of tools used are (but there are many many others) :

Use of these templates is encouraged to help formulate thinking as well as serving as a set of checklist items as part of building the strategy.

A good business strategy is one that is ultimately data driven. This isn't at the expense of intuition and gut instinct, however, that gut instinct must be qualified in someway with data.

This might come from data the business already has (if it has existing product lines), but should typically consider factors outside the business itself such as, market evolution & trends, areas of growth and decline.

I've worked for businesses that have leverage services of companies like Gartner for this “data driven strategic due diligence” to base some of the arguments made in the business strategy.

Making use of these services evidently needs to be done the right way round. They shouldn't be viewed as a tool for providing selective justification.

So far, we have something that looks a little bit like the below where the output is a business strategy document , an example of which is here (note that this example is prepared for sending to an investor. Aka, their ultimately should be a version of this document that is pragmatic into the point).

Step 3 : North Star Metric

Once the business strategy has been written, you're now in a position to identify your North Star Metric (NSM).

The North Star Metric is a metric that everyone in the business knows, and represents how your business generates revenue. Keeping with Amazon as an example, their Northstar metric is the number of purchases per month .

This is because if the number of purchases is growing, it means their position in the market is strengthening. Another way of thinking of the north star metric is like a health check, if the businesses, “realising” product-market-fit, the Northstar metric will also be growing.

There are a list of Northstar metrics available here, which may well help formulate yours.

Key to all metrics is that they must be measurable, and as such, even if you are just starting your business, investing in some means of generating this number, making it accessible to yourself (and colleagues if you have them) is a useful step. In my own experience, this was a Google sheet that tracked number of uploads in a rolling seven day period for a social media app concept, I was working on (see my project section for more on that one).

Step 4 : Defining OKR’s

The OKR (Objective and Key Result) framework has become increasingly popular for businesses to manifest their business strategy.

OKR’s are, in the most basic form, simply a set of measurable objectives that, in turn, drive the north star metric. For each there should be a body of evidence behind why this objective is necessary and is worth placing such particular focus on. They, like the Northstar metric, are artefacts that everyone in the business should ideally know. This necessitates them being concise, tight in their focus, and above all necessary.

There is a broad range of opinions on how many OKR’s you should have (see here). Personally I don't think targeting a particular number is relevant, you need to define as many as you can operationally deliver against. In short, there's no point defining an OKR if you don't have the bandwidth in place to deliver it.

Creating OKR’s

Given a businesses strategy and North Star Metric, the process of formulating OKR’s typically can be started by considering the demand and supply sides of the business.

For example, in a marketplace business like Amazon, OKR’s on the supply side might be :

  • OKR 1 : Increased the number of merchants on the marketplace from BASELINE to TARGET.

  • OKR 2 : Improve merchant support query resolution time from BASELINE to TARGET.

    And on the demand side, we might have.

  • OKR 3 : Reduce cart abandonment rate from BASELINE to TARGET

  • OKR 4 : Improve the product viewed to transaction rate from BASELINE to TARGET

For an established business there will be a baseline and a target, but for start ups, there will be just a target.

Establishing the target
The target value is established by considering the contribution needed by this OKR to move the north star metric by a desired amount.

For example (keeping with the Amazon example from earlier), our NSM was increase the number of purchases per month. Let's say that our business is seeking to generate a 5% improvement in this number. We need to use data to understand what the target needs to be for this OKR to move the NSM by 5%.

In a previous role, I set about this task by getting data (measures) from across the product, marketing and sales teams, dumping it all into a spreadsheet, and then deriving a correlation score (between -1 and 1) that indicated the strength of the relationship between each measure and our NSM. This highlighted the most impactful ways (in the current product) we had for driving the NSM.

Considering the example of the cart, we might say that this represents a very powerful lever for us to improve(and hit) our NSM. Hypothetically, the data associated with the cart abandonment rate has a correlation of 0.9 (very high) with the NSM of increasing the number of purchases per month, and hence we could be confident, that even a slight improvement in the cart abandonment rate, will have a demonstrable impact on our NSM.

In lieu of having this data, you will have to use your best guess and judgement to identify the target, but this can still be built on some assumptions that you can log in a spreadsheet (coversion rates over a funnel for example) and update when your product or service starts generating real data.

Without skipping, too far ahead to the product management specific section of this page, this represents one of the key skills a PM should have, aka to work out in the most expedient way, what impact will this feature have on the OKR, and by extension, the NSM. Getting this right insures that the Squad (more on this later) is focusing on high value areas.

The risk of not setting OKR’s effectively is that squads work will not ultimately drive the NSM leading to fatigue, burnout, and unnecessary frustration across the business.


A final point on OKR’s that it’s worth highlighting is that they should run for extended periods of time, they are not effective if they are set up and decommissioned rapidly. According to this article (and this one)a quarterly review of the OKR’s is prudent, I personally feel like it works best if they are reviewed every six months, but this is very much driven by the stage of your business, and how fast the space around your business is growing/changing.

With all this being said , you should now have something like the below built off the business strategy.

Step 4 : Operating Model

Once OKR’s have been established, you are now in a position to start considering the operating model. In this section, will assume that there is already a team in place, or that you have funding and need to work out how to deploy it. In my experience, I've never had any visibility of this process directly, however, talking to some colleagues things might shake out as below.

The COO will start by taking the businesses strategy (and it's OKR’s) and working out what the minimum requirements are to meet the key results of each from a staffing, Technology, and process standpoint. The COO will be balancing several factors, including, how fast the business needs to achieve these objectives, as well as the balance of existing resources.

The CPO or Head of HR will then review these requirements and conduct an analysis of the roles and responsibilities required to implement the operating model. They will also consider, if anyone with any organisation currently can/would like to be moved into a position to aid in fulfilling the objectives.

The CFO will, ultimately sign off on the budget for the staffing requirements established by the CPO if new hires are going to be brought in.

This is a phenomenally challenging task as is the first time the business is strategy comes into contact with the reality of running an organisation. In a perfect world, all of the right people can be organised in a transparent structure, where OKR’s are effortlessly delivered and the company grows endlessly into the future. The reality of courses is that this is not a likely scenario, there will be a proportion of people at the business who don't agree with the direction, there will be new hires, but don't work out, and there will be others that are frustrated at the lack of progress by a particular team.

In the businesses I've worked in this is where the adage no plan survives first contact with the enemy resonates most strongly with me. To me it feels like the skill of running and operating a business is handling the changes in the businesses strategy that are necessitated by market factors, as well as decisions that turned out to be bad.

In seeing these things unfold, I've observed how important being very transparent about why the business ”needs to head” in a particular direction is to securing that buy-in. Moreover, the data used to derive the strategy should be treated like a product itself, it should be simple, easy to understand, and relatable to all of the people in the organisation.

Being able to tell this story with data is the kevlar I think all senior leadership teams should adorn themselves in, as it seems to make a huge difference when things don't work out mainly because, if the strategy has been informed by data, and rationalised with it, it can never look like it was one or two peoples opinion that pushed the business down a particular route that's turned out not to be so fruitful.

With all that being said, the operating model will ultimately take the form of an updated org chart, where each of the functional areas of the business has an established “Head of” and their associated KPI for themselves and the function.

Below is a high-level illustration of this :

Establishing KPI’s

Every role in the above will have a set of KPI’s drawn up that describe what effective functioning of their business area should look like.

The below are just some very top line KIP’s each functional head might be focusing on:

  • CFO : Cash flow management and profitability ratio’s

  • COO : Operational Efficiency and resource utilisation

  • Chief-of-Staff / HR / CPO : ENPS, Driving performance

  • Head of Technology / CTO : Development work (tickets/cards) burn down rate

  • Head of Sales / CSO / CRO : Value of SQL’s (Sales Qualified Leads) / pipeline value

  • Head of Marketing / CMO : Volume of MQL’s (Marketing Qualified Leads).

  • Head of Product / CPO : ARPU, NPS, squad learning rate

  • Head of Data/ Analytics / CDO :

These KPI’s are the elements of a roles responsibilities that are agnostic of any specific point in the strategy, or how that department will relate to / be expected to manifest the strategy. They are, as i say, essentially ensuring effective functioning of the department.

Dependent on the size of the organisation there may be hundreds of people working under each of these functions, with KPI’s delegated downwards. While for startups, there will be several roles being done by one person. For example i have worked for businesses where the founder was the CEO, CPO and CTO with the other being effectively the CFO & COO. Point is KPI’s make sense at a size where organisations need to be clear about who is responsible for what and be able to “measure” the contributions of team members, this is necessitated by some businesses sooner than others.

Squads and the Product Function

At last we reach the realm of Product Management. While the CPO will have been involved in the strategy formation, were now at the level where the strategy, expressed as OKR’s needs to be worked on.

Enter the Squad. The concept of a squad has been around a long time. One of my first experiences of them came from reading this paper from Spotify which demonstrated how they were building squads around OKR’s. This was back in 2012, and the field has come quite someway in that time, the paper is a very interesting read, and I would encourage anyone who is going to participate within a squad, let alone someone running it, to read this over as for me, it really helps ground some of the core concepts.

In the below, I will endeavour to set out how squads are formed, how they function on a day-to-day basis, and specifically in my recent roles, as a growth product manager, and laterally as a senior growth product manager how some of these activities can be discharged.

I would like to point out that some of the guiding principles of working in squads is that their internal processes, ceremonies and tools are self defined, so please take the below as “a” way but by no means the only way.

Forming a squad

Squad formation starts with making an assessment of what resources in a business are best positioned to deliver against the OKR (around which the squad is to be formed). With that in mind a typical squad will have

  1. Leader (product manager)

  2. Developer(s)

  3. Domain expert (sometimes this is required)

Across these three roles, the product manager has the ultimate responsibility of defining what the squad works on and coordinates with other functions within the business (marketing, UX design, sales as well as representatives of the C-suite). They are the conduit/API for the businesses desired outcome, expressed and measured through performance against the OKR. The product manager is responsible for maintaining the product roadmap, as well as deriving the top level strategy for how the squad will meet the objective and key result.

The developers role is to feed into that process, implementing features and functionality as well as actively participating in facilitating Minimum Viable Tests (MVT’s), through to MVP’s and beyond.

The domain experts I've seen (and worked with) can be added to the squad to plug any direct knowledge, gaps or appreciations that the product manager (who may be new to a field) doesn't possess. Their role may be to provide a sounding board for the product manager (and the wider squad) as they work on their hypothesis.

Laying the ground work

Once the product manager and resources have been allocated to the squad, the product manager, will embark on setting up all of the preliminary infrastructure for the squad, this may include, slack channels, new project areas in Jira, as well as generic access to data resources that they (as product manager), and the broader squad will leverage.

Beyond, laying the groundwork, it's important to keep in mind the overall flow of the activities. From this point onwards. To that end the diagram below illustrates each of the phases and activities the product manager and the squad will be engaging in.

  • The product managers first move will be to build a list of questions that are relevant to the squads focus that seek to build a comprehensive understanding , these can then be handed to the data/BI function to collate further. For ease, moving forward, let's define a hypothetical squad

    Objective and key result : Increased the number of merchants on the marketplace from 200 to 250.

    As such my preliminary list of questions might be :

    General Analysis

    • What is the churn rate of merchants on our platform?

    • What product categories sell the most on our platform?

    • How long do merchants typically have to be on our platform before they make their first sale.

    • What is the churn rate of merchants after they have made at least one sale?

    Funnel Analysis

    • How many Ads are we serving across our key marketing channels.

    • What is the conversion rate on those ads, broken down by source (LinkedIn, Facebook, Google etc)

    • Around what messaging I'll be seeing highest conversion (merchant signup).

    Behavioural Analysis

    • By Page type (landing page, search page, top selling page, account page etc) what areas of the site do merchants make most use of?

    • What features on those pages are used most heavily?

    • What sequence of pages viewed most commonly results in a new merchant signup?

    Competitor Analysis

    • What features do our competitors expose?

    • What information do they collect as part of merchant account creation?

    • Considering publicly available financial data, which competitors are most profitable / have grown the most in the last 2 years.

  • Once the list of questions has been formulated, the product manager will work with the business intelligence and analytics function to gather the data that relates to those questions. In my roles to date the platform used to aggregate data across the product will either be Tableau, or PowerBI.

    Working with the data team, you may be able to refine your list of questions, and highlight those that are not captured in the data. If you are working in a start-up with limited to no data, Power BI (part of the Microsoft 365 suite) is useful as gives you some self-serve capability (connecting to a MySQL db and pulling data for analysis) in a way that I haven't personally found when using Tableau.

    Given the resulting set of data, we should be able to start making some hypothesis around areas that :

    1. Could be improved in our current offering

    2. New features and capabilities that others in the space are leveraging

    3. Pain points that we can identify in data, that if overcome (throughout, optimisation or new features) we can unlock the desire growth (rate limiting step).

    Armed with this information, the product manager will formulate a document outlining some of the key takeaways from this analysis. This will be circulated in advance of the squads first meeting.

  • As mentioned above, as part of kick off, the squad will need to review the analysis that has been prepared. The key in this first meeting will be to establish questions that have yet to be posed of data, what further areas of analysis need to be undertaken, and as a result, what further hypothesis can be drawn up that have yet to be captured.

    A note on hypothesis formulation

    As noted above the product manager, in conjunction with BI will have started to consider what the top level hypothesis are for unlocking the growth needed to fulfil the squad objective (25% increase in the number of merchants). Hypotheses can be written in a set format as below.

    We think that if we introduce X it will have a Y(%) improvement in the number of merchants on the platform.

    Each of these statements should be backed up with data. There is often a temptation to assume that data must be numeric, this isn't necessarily the case, often, considering start-ups for a moment, there is little to no primary data (that is numeric) available, and in such instances, the data that can be arrived at might come from secondary sources, or start to form the basis of a survey in order to capture that primary data.

    No matter which source of data you use, the key is to have your hypothesis driven by some data (whether it be quantitive, or qualitative).

    The kickoff meeting with the squad should as outputs be :

    1. Additional hypothesis

    2. Additional questions of existing data

    3. A list of questions that cannot be answered directly from the data that exists at that moment in time.

    The product manager, will take these away, and start to build a Notion page (or confluence) that documents the hypothesis that are being arrived at.

    They will also start to work on (in conjunction with BI) how the remaining questions could be resolved. This may take the form of surveys or speaking directly to users (in this case merchants).

  • One of the key skills of a product manager is to know how to understand users pain points. Talking to users is perhaps one of the most direct ways of getting this feedback. While surveys are fantastic for answering questions on mass, for a general sense of what users think, being able to catch up directly with key users on the phone or video call (or even in person) has led to a number of breakthroughs in products that I have worked on, that would not have happened if we did not engage with those users so directly.

    The best example I have of this is in a previous role, amongst a key segment of users, we did not appreciate the sense of community that users of the product were experiencing, and to that end, that sense of community was integral to their use of the platform.

    In hearing this from a number of users, we decided to survey abroad spectrum of the base to see how, amongst the list of factors, where did the sense of community factor in there preference or otherwise to use our platform over a competitors. Nearly 60% of the respondents highlighted the sense of community as being central to there reasons for sticking with the service.

    As a result of this feedback, we drastically changed the road map, focusing on a set of features that tried to facilitate greater interactions between users. This also led to the creation of a new metric for assessing the health of the community, which was a function of how many users had contacted another user in the last week.

  • Much like a start-up, the squad in its infancy will come up with a large number of ideas, and also like a start-up, new ideas sessions need to be held at points where the squads hypothesis have not turned out as expected, and a pivot (keeping with the startup analogy) is required.

    The idea session is a great place to bring in the domain expert, as well as representatives of the sales and marketing function to participate in the ideation process. It is very important, however, to ensure that all stakeholders in the meeting are aware that they are equal, and that there are no such things as “bad ideas”.

    You can use this template to run the session.

    Typiically we will have 25 mins for ideas.

    At the end of the allocated time, the squad will go over all of the ideas on the board under each problem area, where it will be upon the product manager to highlight ones that are particularly interesting.

    If we were to host a hypothetical ideas session around our OKR of increasing the number of merchants on the platform from 200 to 250, and, for the sake of argument, let's assume that the data analysis has fashioned us with a number of problems statements (that are themselves linked to hypothesis we have about our uses).

    Problem statements (derived from our hypothesis)

    1. I find the sign up process long and complicated.

    2. I don’t get clear guidance on what next after ive completed sign up

    3. I don’t know how to go about making my first sale.

    Post meeting i will collate these ideas and start to identify the key themes.

    Themes tend to be related to either the on site experience, or communication with users at various points of the tunnel as they come to the site

Ideas Session Template

  • Having established a set of initial ideas from the squad, the next step will be to identify the core themes within those ideas. The tends to be a number of common ideas that people come up with. Your task as the product manager is to bring those together in a coherent set categories. This is to aid in being able to explain the strategy to the squad as well as externally to the rest of the business.

    In our hypothetical case (where we are trying to increase the number of merchant accounts on a marketplace platform), there might be a number of themes. Some that relate to the on-site experience while others relate to the way merchants are brought onto the platform.

    Merchant Onboarding communication Themes

    Theme : Incentivising merchants to complete their signup process

    Ideas ….

    Theme : Reactor, email, marketing, collateral around untapped merchant segments

    Ideas ….

    On site improvement themes

    Theme : Making the signup process more navigable

    Ideas ….

    Theme : Updating the post signing experience to be more informative

    Ideas ….

  • Once these teams have been established, you must leverage the data you have available and your own intuition to identify what the most impactful themes are in those you have listed. Impact should be measured against the themes ability to make a significant contribution to the success metric for the squad. Using ICE scoring (see the section below for more on this) is to granular at this point, as you don't have a meaningful way to talk about Confidence, let alone Ease (the other two components of the ICE score).

    Once you have made this assessment, you can essentially divide up your themes into those that you are going to work on NOW, those that you were going to work on NEXT, and everything else can be left to the FUTURE.

    From an outward facing standpoint, this constitutes your high-level preliminary roadmap. If organised in a Kanban board, we would have 4 columns NOW, NEXT, FUTURE, DONE.

  • There are many ways companies go about prioritising what to focus on one mechanism is ICE Scoring or RICE scoring.

    ICE is an acronym that stands for Impact Confidence and Ease.

    Impact (scored between between one and 10) reflects how impactful we think this idea will be. For example, changing the colour scheme of the signup form for New merchant accounts, is unlikely to be particularly impactful, so we might give this an impact score of 1 or 2. however, if we were to redesign the signup flow, to be more step based, we might suggest that it's impact as much higher (6 or 7).

    Confidence (scored between 0.0, and 1.0) reflect the degree of confidence we have in the impact we have envisaged. For example, if there is a very large body of data, that suggests that uses would prefer a more “step based” signup process (as a result of some survey response data perhaps), then we would be able to say that we are very confident that the degree of impact we assessed (6 or 7) is something that we could realise. This example, let's say our confidence is 80% so 0.8.

    Ease (scored between 1 and 10), is that the discretion of the development team. They will make an assessment of the task were they complete it. As 1 denotes are very hard task, and an exceptionally easy task, we might say that the introduction of a step based signup process for new merchant accounts is somewhere in the middle (5).

    The ICE calculation

    I x C x E = ICE ( 6 * 0.8 * 5 ) = 24

    Given the examples above, we have ended up with an ice score of 24. This is 24 out of 100 and represents a reasonable score. There are very very few pieces of work that will ever score a perfect 100 (in my experience, never in fact), but you want to make an assessment of all of the pieces of the ideas based on their ICE score. For ease, I compile these in a spreadsheet and order the column by the calculated ICE score to get a sense of which ideas we will be engaging with first.

    What about RICE?

    RICE scoring is very similar to ICE, with the added component (R) standing for reach. This is useful in cases where you want to specifically call out the number of users that are going to be impacted by this feature. This could be represented by a percentage of the total user base, or proportion of the total prospective users (if you are a start-up).

    It's important to note that these scoring mechanisms are just tools to help way up ideas, this doesn't have any predictive power on whether these ideas will work as expected.

  • It's important that the squad feels completely engaged, and to that extent you need to be able to cultivate the sense of ownership. Dependent on the exact composition of your squad, this may be somewhat self organising (if people have specific experience in one area) but in instances where there is a fundamentally new team, it's good to give people the opportunity to put their name down for a particular theme of work. You might have one or two people to a particular theme, their role will be to delivery items related to that theme and leverage the product manager within the squad to assist in making decision + interfacing with teams outside of the squad.

  • Before considering an idea as being “worthy of development” it's always useful to consider what the small test (MVT) is that could be done to get some sense of whether building out a feature into a minimum viable product is the right thing to do.

    You notice in the above ICE calculation, the element that contributes most to the score is the confidence. You can have a very easy task, that has incredibly high notional impact, but if you cannot establish a reasonable degree of confidence in that impact, the score will be very low.

    To that end, using one of the concepts from the idea session where we considered, that new merchants could be given analytics on the “top selling categories” of products, so that they are able to make more informed choices about what they should sell. Our MVT might in be to create an email campaign that leverages data that we already have in Tableau about top selling categories of products. We could run this email campaign for one week, highlighting the top five product categories, and see if the click to open rate on this email, is proportionally higher than that of others that we send. If this test returns a positive result, it gives us the license to increase our confidence that buyers will find the feature useful when it is introduced into the product.

    Typically, the idea session provides a number of big ideas, for which there is either limited data available, or none. To that end the minimum viable Test is an important steppingstone en route to building out on those bigger ideas.

    For example, let's say one of the ideas was that merchants should have a dedicated mobile app that will help them be notified when they make a sale, and they need to ship something from their inventory. This is a very big idea, and it will need to be proven how the app as a concept will actually deliver the increase in merchant accounts that the OKR has been set up to provide. In such a case, there would be a whole set of minimum viable tests (as well as user interviews and surveys) conducted to ensure that if the app is developed, it recoups the internal cost of producing it in the first place. To that end the squad should have somewhere between two and five MVT’s constantly running so that even those big ideas are getting chipped away at, reducing the risk that a big bet turns out to be a bad one.

    A great example of this will be something like the Apple Vision Pro. This, as a piece of product development will have taken the best part of a decade of small tests, R&D, and a huge amount of user feedback, about a range of issues to do with using the product, how such a product would make you feel, and how others will perceive you if you were to own one all to make the product release as close to a sure fire bet as its possible to be.

    The MVT prompt below is one ive made to help the squad think about how they can test their ideas. You need to think laterally about what your really interested in learning, and then marry it up to the tools you have at your disposal for running such a test.

    The output from your MVT’s should be a strong gauge (likely numeric) about the ideas viability. This will take the form of :

    Users that interacted with the email were 6% more likely to complete sign up than those that didn’t receive it.

    For example

  • With the minimum viable tests out the way, it's time to start thinking about what that minimum viable product could be that builds on the success of the test. The minimum viable product is the smallest piece of functionality that could be offered that a user will see benefit in. The MVT’s should have established the elements of the product that need to be present as part of an MVP to be useful. The phrase “user delight” is often promoted as the sensation that you want to leave the user with, even if this is on a very small scale in the first instance.

    Given the example above, where we had the idea to provide an analytics dashboard for merchants, to know what product categories are trending currently. Our minimum viable tests saw us send a range of emails, one which had a list of the top five categories every day, another containing a picture and description of the top product of the day, and another, which showed links to the top performing merchant accounts by day on the platform. Of all of the tests done, the ranking of top product categories got the most engagement, this will form the basis of our MVP.

    As a product manager, I will prepare a wireframe for the MVP and PRD (product requirements doc), highlighting the key elements of the user experience that we want to introduce, and get some feedback from stakeholders both in and outside of the squad.

  • With the MVP defined and the designs specified, the work will be divvied up into cards (tasks) in Jira (click up, Monday, Acana etc..) to be worked on. 

The product manager will work with elements of the design function to refine and build the asset pack (if any are required) using Figma or Sketch. This will be a great opportunity for the squad to provide feedback on the design and trade-offs between simplicity of design vs simplicity of implementation.

    This can be the domain of the project manager if you have one, but more often than not, the product manager may be doing this activity as well.

    Tasks in agile software development to fall into one of the following categories :

    Initiatives (Mapped to themes) : A collection of epics that relate to a particular journey, a usable take through the product

    Epic’s : a collection of tasks relating to a part of the initiative

    User stories : A collection of tasks that relate to a particular journey

    Task : A particular task within an element of the User story.

    Subtasks : The development team uses these to aid in the management of work items amongst themselves.

    These tasks are typically managed either through a scrum, kanban or scrumban mechanism. In almost all of my roles, it is this latter variant (scrumban) I have most experienced with. This involves having a Kanban board to host the cards, then moving through the states (that can correspond to distinct elements of your design and development functions). Ergo column, we might have in our kanban board might be as follows :

    Design Backlog > Design In Progress > Design Review > Frontend Dev Backlog > Frontend Dev Progress > Backend Dev Backlog > Backend Dev Progress > QA > UAT > Ready to Merge > Deployed

    Work is moved into a sprint on a fixed cadence (typically two weeks) , where, at the end of every sprint there is a demonstration of working software, planning activities for the next sprint, and retrospectives periodically to identify improvements to the “ways-of-working” between functional teams.

  • Go to market typically entails an incredibly diverse set of activities, so I will make some general statements here :

    Messaging and Positioning: The PM will work with the marketing function to craft clear and compelling messaging that highlights the unique value proposition of the new feature. (Clearly communicate how it addresses pain points or improves existing processes for your target audience.)

    Launch Plan: The PM will develop a detailed launch plan outlining the sequence of activities leading up to the release. This may include pre-launch teasers, beta testing, early access for select users, and the official release date.

    Sales Enablement: The PM will work with the sales and support teams to equip them with the necessary knowledge and resources to effectively promote the new feature to customers. Provide training sessions, create sales collateral, and develop FAQs to address common inquiries.

    User Onboarding and Education: The PM will work with the design team to develop user-friendly onboarding materials and tutorials to help users understand how to use the new feature. This may include walkthrough videos, step-by-step guides, and interactive demos.

    Feedback Loop: The PM will work with BI & support functions to make sure the needed tracking is in place. Key is to ensure that data is being collected from users post-launch, thereby enabling the squad to iterate & ideate further