Category: Roadmap

  • Product Features and the RICE Score

    Product Features and the RICE Score

    “Impactful” product features are the backbone of every product-led company. “Impact” is one of the axes of the RICE prioritisation method – we revisit this valuable approach to getting the right tasks into your sprints.

    Like most product companies, we struggle to triage and prioritize the mountain of tickets into sprints. Luckily at Contextual we can use our own product to add contextual help instead of making even more tickets for engineering.

    Your Mobile and Web Apps are competing with other apps to get your users attention. You need each of your product features help the user get their Job Done (JTBD) – this means the right features at the right time and with minimum user confusion.

    In the routine of a product-led company, user journey mapping is a crucial task in order to ensure the greatest possible user experience. As there are a lot of things to consider in user journey mapping, prioritisation helps you be more organised with your product features, and it enables your App to become more impactful.

    But, (you may ask ????,) based on what criteria should you prioritize product features? A great place to start is the RICE scoring model, a prioritization framework that shines light on the value of your ideas. It helps your user journey mapping through four factors: Reach, Impact, Confidence, Effort. Together, they form the acronym: RICE.

    RICE – Grain by Grain

    A good prioritization framework can help you see your product features in a new light, so that you can make sure you’re making a good decision for your company. So, when you make time for user journey mapping, having a system that allows you to see your product clearly and objectively comes to your advantage. RICE helps you evaluate the four main areas of any project idea. 

    Reach 

    How many people can you reach with a new product feature in a given timeframe? Will they benefit from it? The score in this case is the number of people you estimate to be reached by the new feature. 

    Impact 

    The Impact score represents, as its name suggests, the estimated impact the new product feature can have on the people you reach. For instance, you could ask: ‘How much will this feature affect product adoption/conversion rates?’ Or, ‘How will the user experience benefit from this?’

     

    As Impact is hard to measure, a multiple-choice scale is usually used for estimation purposes: 

    • 3 – massive impact
    • 2 – high impact
    • 1 – medium impact
    • .5 – low impact
    • .25 – minimal impact 

    Confidence

    A product-led company is always enthusiastic about great ideas and implementing them when it comes to product features. However, to be more realistic, the RICE scoring model advises that you factor in the level of confidence you might have with product features and their releases. In the long run, this estimation will help with product adoption among your users.

     

    Percentages score Confidence, as follows:
    100% – high confidence

    80%   – medium confidence

    50 %  – low confidence

    So, how confident are you about the reach and impact of a new product feature? 

    In order to achieve your product feature’s RICE score, you have to follow the following formula: 

     

    Reach × Impact × Confidence
    ___________________________
    Effort

    Why is Effort Crucial in Prioritization?

    Effort is the denominator in the RICE equation. This factor represents the cost a product-led company pays when implementing a new product feature.

     

    To quantify Effort in this score model, you estimate it in the same manner you do with Reach, Impact, and Confidence. In this case, Effort is estimated by analyzing the work one team member can do in a month. 

     

    The highest possible Impact with the least possible Effort is desirable when it comes to product features and their releases. By minimizing the time and human resources you put into a feature release, you gain them back for other areas of your product. 

     

    Effort is the most important out of the four RICE factors, as it can make or break a good idea. If you have great Reach and Impact, but the feature you envisioned requires most of your team and a significant amount of time, it might be better to rethink the idea or to use a different approach for it.

    How to Minimize Effort?

    That’s an easy question to answer: use Contextu.al!

     

    Of course we jest – there is so many features you have to implement and those require solid development work. But Feature Announcements and Guidance – in fact all elements such as videos that deepen user engagement can be helped by using Contextual.

     

    We strive to deliver product-led growth through announcements, guides, tips regarding product features, the onboarding process, and even feedback!

     

    With Contextu.al, you wouldn’t have to worry about hard-coding, because the Effort on your part would be minimal. Your top priorities are even higher priorities for us!  Putting more effort into implementing new releases is the thing of the past with us. 

     

    As an added bonus, with Contextu.al, the Impact and Confidence are also increasing. How, you ask? With us, you can get rapid feedback and measure results in no time. This will give you and your team the confidence to implement the desired changes later by hard-coding. 

     

    If you want to make your app fly, don’t hesitate to book a demo with us today! You won’t regret it. 

    Image Credit.
  • “Slow” is a dangerous place for products

    “Slow” is a dangerous place for products

    This paragraph caught my eye:

    “Slow is a dangerous place for a product company to be. Slow product teams tend to be outcompeted by fast ones. We complain about how Figma and Slack don’t feel native, but why are most of us using Figma and Slack? We’re using them because they outbuilt and outcompeted their native competitors. There are so many things that could improve in these products, but they’re the best tools yet built for their purposes.”

    For product teams, releasing and syncing the features across your IOS, Android and Web platforms is a mammoth task. You release a new feature and then nobody uses it. You release on one platform and users complain its not on the other platforms!

    With Contextual we allow you to not only announce new features but also test different engagements or interest in a feature PRIOR to building.


    Lets say you’ve received some feedback from your customer success team, or using interview products like https://greatquestion.co/ or https://dovetailapp.com/

    You want to drill in and get a sense if other users would value this. With Contextual you could:

    a) ask for feedback with a question – a simple popup message targeted at a specific audience segment lets them single click answer to “take their temperature”

    b) Do a mock announcement for a feature:

    1. Users who click thru on the announcement can be measured.
    2. After clicking thru, you may ask the users for their level of interest.
    3. Promise to get back to them when its released.

    This time-tested launch-hack from that lean startups have been doing for a decade. It may appear a but scammy or disingenuous but inApp you already know the user and if they arn’t interested, they will just click away. No harm done but valuable data to be gained.

    This animated GIF shows how to do this with Contextual in a few minutes.


    The starting quote comes from an excellent post by Allen Pike, (the owner of Steamclock Software) on when/why product teams should prefer to use Native or Hybrid app development. The main point being – the more code platforms you support, the:

    • greater cost to your team to implement
    • greater cost of co-ordination
    • inability to iterate and test fast

    These are absolutely the problems Contextual helps try to solve – both because we provide libraries for ReactNative, Cordova, Ionic, Capacitor and of course Native IOS, Android and Web!

  • Don’t build shiny objects

    Don’t build shiny objects

    Shiny objects are the features you release that arn’t supported by evidence the customer needs them.

    Airwallex’s Richard Jeremiah gives his perspective on how Product Teams should triage the firehose of ideas, feedback and opinions that all compete for precious sprint resources.

    In this short video, Contextual’s David Jones asks Airwallex’s Richard Jeremiah how they reduce down all features into the things that get built.

    He cautions that all product teams have a tendency to  “Veer off the path” :

    • moving away from (measurable customer) “outcomes” to “output”.
    • Teams often shy away from uncertainty to just making and releasing the new shiny objects.

    Outcomes vs Output

    For Airwallex and “Outcome” is focussed on customer value – this generally relates to an Objective or a Key Result in an OKR.

    In contrast, an “Output” is just the result of keeping busy. This is often features that are built in isolation from customer needs. In other words, output is that new shiny objects are something the team saw in a designer’s blog post or a competitive product.

    The challenge, Richard says is that “Outcome” is always way less certain than “Output” – an output is a known quantity, its just a matter of applying the resources and getting it released.

    An Outcome requires much more validation and rigour to verify:

    • Are we building the right things?
    • Are shipping valuable things for customers

    “Solving core customer problems is one of the great challenges of Product Development.” and “Get inside the head of the customer.”

    Triaging competing requests

    At the top of the product teams work funnel is a massive amount of options:

    1. Bugs to be fixed
    2. Technical debt to be re-factored. Scale and stability issues.
    3. Customer feedback captured in Zendesk etc
    4. Sales people claiming its imperative to implement ABC feature for XYZ prospect
    5. Team opinions
    6. New shiny objects and technologies
    7. validated feedback from customers
    8. results of experiments, hacks
    9. biased opinions from the product manager.
    10. and that old favourite….the fly-by CEO visit about something that’s been bugging them.

    There is a lot to be triaged and having something like RICE is fine, but it’s rudderless.

    Similar to what Zip‘s Patrick Collins advised the sprint needs to be filled with jobs that match to the customer and company imperatives.

    Specifically, Richard says: Strategy—>OKRs—>Measures that reflect toward an Objective or Key Result/Outcome.

    This top-down approach leads to using tools like Teresa Torres’ “opportunity solution trees” to ideate a range of possible technical and non-technical solutions.

    From there a weighting or “sizing” (Richard’s term) for each initiative is used as another filter for what makes the sprint.

    Summary

    The summary is that new shiny objects will always be tabled as solutions to product problems or opportunities. 

    Its correct – the shiny objects may be a terrific solution! But you MUST run them:

    a) through the lens of the customer’s needs

    b) the organisational priorities and OKRs.

    Banner Image credit

    Transcript

    00:03 – some of the lessons that i’ve

    00:04 – learned over my career but it’s very

    00:06 – very easy for

    00:07 – teams to veer off the path away from

    00:10 – outcomes towards output

    00:11 – it’s very easy to veer off the path of

    00:14 – experimentation uncertainty and trying

    00:16 – to nail down something that is certain

    00:18 – which is

    00:18 – in many cases look at this shiny thing

    00:21 – that i’ve built

    00:22 – and so trying to embed that into your

    00:25 – day-to-day

    00:26 – um check-in with the team i think so

    00:29 – anyway you’ve got these squads

    00:31 – how do you actually make sure you’re

    00:32 – building something that people actually

    00:34 – want

    00:35 – so yeah i mean that’s a that’s a big

    00:38 – question

    00:39 – um and it’s it’s really challenging i

    00:42 – think i think this is

    00:44 – you know making sure you’re shipping

    00:45 – value to customers is the

    00:47 – it’s one of the defining aspects of

    00:49 – whether you’re not gonna be successful

    00:50 – as a business

    00:51 – um i mean that’s that’s like are you

    00:54 – well suited as a business to do

    00:55 – to do that and all those stuff there’s

    00:56 – lots of other questions but one of them

    00:58 – is generally

    00:59 – are you solving a core customer problem

    01:01 – is

    01:02 – one of the great challenges of product

    01:04 – product development look our focus is

    01:07 – and my focus has been for a long time um

    01:10 – i i spoke previously it’s all about

    01:12 – focusing on the outcome

    01:14 – and not focusing on output that’s the

    01:16 – that’s the key

    01:17 – um it’s very natural as human beings

    01:20 – that we want to focus on

    01:22 – the output and not the outcome and one

    01:24 – of the reasons for that is output is

    01:25 – certain if you

    01:26 – if you apply effort you’ll get you’ll

    01:28 – have something to show

    01:29 – for it in terms of that you know it

    01:32 – could be

    01:33 – whether it’s a new page that you’ve

    01:34 – created whether it’s an experience

    01:36 – enhancement thing you’ve done whether

    01:37 – it’s a new feature

    01:38 – that’s available on your on your

    01:40 – platform you’ll have something to show

    01:41 – whether that thing matters or not that’s

    01:43 – the question right and so the

    01:44 – outcome is always way less certain and

    01:47 – we have a natural information as people

    01:49 – to want to you know shy away from that

    01:51 – uncertainty towards something that’s

    01:52 – certain

    01:54 – you have to be relentless in that focus

    01:56 – on the outcome

    01:57 – and that outcome could be whether it’s a

    01:59 – commercial outcome that you’re trying to

    02:01 – achieve by a meeting a need or a

    02:03 – customer need itself

    02:05 – you know that’s where your focus has got

    02:06 – to be so for me

    02:08 – trying to ensure that you’re shipping

    02:09 – value it’s all about

    02:11 – focusing on the outcome um and

    02:15 – and then you know if the outcome is

    02:17 – customer related

    02:19 – ah yeah so you sort of threw that in at

    02:21 – the end but it sounds like the most

    02:22 – important thing

    02:23 – so you you know what goes in the top of

    02:25 – the funnel

    02:26 – is a whole bunch of things you’ve got

    02:28 – opinions you’ve got sales people walking

    02:30 – back saying

    02:31 – you know they’ll come on board if you

    02:32 – actually develop this feature

    02:34 – uh you know you you know that sales

    02:36 – people are always dragging in between

    02:38 – you know bits of roadkill they say that

    02:40 – this is definitely the one that’s going

    02:41 – to

    02:42 – break the you know it’s really going to

    02:44 – the company will break out

    02:45 – you’ve got opinions around particular

    02:46 – things and then you’ve got disciplines

    02:48 – and customer

    02:49 – so how how are you feeling the top of

    02:51 – the funnel and then how are you triaging

    02:53 – that to get to this

    02:55 – output that’s actually used by a

    02:57 – customer

    02:58 – used by a customer yeah sure or even

    03:01 – valued

    03:02 – valued by a yeah yeah so

    03:05 – we um the general the general approach

    03:07 – and i

    03:08 – alluded to this before with you know we

    03:10 – have a strategy we have a set of okrs

    03:13 – that that then outlines um you know

    03:16 – here’s some some measures we’re going to

    03:18 – try and deliver over the course of the

    03:19 – quarter

    03:20 – and those measures reflect progress

    03:22 – towards an outcome or an objective

    03:24 – right what we take from there is trying

    03:26 – to understand

    03:27 – what are the various opportunities there

    03:29 – are to better serve the customer in a

    03:31 – way

    03:32 – that’s going to drive that particular

    03:33 – key result and

    03:35 – getting an understanding of that is all

    03:38 – about trying to get

    03:39 – under or inside the head of the customer

    03:42 – and there’s a lot of ways to do that

    03:45 – and you know you have to you want to use

    03:47 – all the tools you’ve got your disposal

    03:49 – sales people they are one of the tools

    03:51 – yes they have

    03:52 – they’ll have a lot to say that

    03:54 – oftentimes will be focused towards

    03:56 – a feature and a solution and they’ll

    03:57 – tell you about the solution

    03:59 – i mean one of the things is to try and

    04:01 – step back from that and say well hang on

    04:02 – what’s this solution actually trying to

    04:04 – achieve

    04:04 – and refer back from that some of it is

    04:06 – talking to those sales people all those

    04:07 – customers support people

    04:08 – and just taking on the journey to say

    04:10 – hey when you talk to your customers

    04:12 – next time they come up with a solution

    04:14 – can you ask why they want to do that and

    04:16 – actually try and work with your customer

    04:17 – support team to drive better customer

    04:19 – insights on the

    04:21 – the why for the customer as opposed to

    04:23 – what they want because

    04:24 – you know if you ask a customer what do

    04:25 – you want they’ll ask for you know

    04:27 – classic saying i want a faster horse not

    04:29 – i want a

    04:30 – motor vehicle so it’s about trying to

    04:33 – use

    04:34 – as many of the avenues that you’ve got

    04:37 – to get customer insight and that can be

    04:39 – you know talking to customers watching

    04:41 – customers engaging with customer support

    04:43 – team as i’ve said you can

    04:45 – um and in fact you can do that yourself

    04:47 – you know one of the things i used to do

    04:49 – a little bit of secret to get onto our

    04:50 – zendesk and start seeing what customers

    04:52 – are saying and trying to understand

    04:54 – what’s going on for them uh and again

    04:57 – you know

    04:57 – use your sales people they have a lot of

    04:59 – insight they’re coming to customers all

    05:01 – the time

    05:02 – but what you need to do is you need to

    05:03 – bring that back to try to understand the

    05:05 – customer’s motivations trying to

    05:06 – understand their needs

    05:17 – okay so that’s a discipline to actually

    05:19 – just basically look at it through the

    05:20 – lens and i guess what are using customer

    05:22 – interviews for that or

    05:24 – yeah so there’s a mix i mean the way

    05:27 – the way you know uh structured it and

    05:30 – the way we’re structuring it and while

    05:31 – it’s the framework we’re using is jobs

    05:33 – to be done

    05:34 – um we at seek

    05:37 – out a thing called a mental model which

    05:39 – is a more detailed deep dive than jobs

    05:41 – to be done into very

    05:42 – difficult tasks and that that is

    05:44 – essentially that mental model is

    05:45 – essentially a shared understanding of

    05:47 – the customer

    05:48 – and what is put against that mental

    05:50 – model the evidence that used to

    05:51 – construct that at

    05:52 – customer interviews uh customer support

    05:55 – insights

    05:56 – um you know experiment data behavioral

    05:59 – data on the platform like

    06:00 – basically any data point you can get

    06:02 – about the customer is used to help build

    06:03 – out that shared understanding of how the

    06:05 – customer

    06:06 – thinks facts their motivations what

    06:07 – they’re trying to achieve et cetera et

    06:09 – cetera

    06:09 – so is a mental model an intersection of

    06:12 – you know demographics slash personas

    06:14 – and job to be done is that is it so yeah

    06:18 – i mean you could segment the mental

    06:19 – model

    06:20 – based on the different personas um but

    06:22 – really it’s just a more detailed view

    06:25 – of jobs to be done you’re getting down

    06:27 – to very discreet tasks as opposed to a

    06:29 – job you know a job is

    06:30 – a manifestation of multiple tasks it’s

    06:31 – like subtasks and sub-sub-tasks it’s

    06:33 – really really granular

    06:35 – and it just essentially represents a

    06:37 – shared understanding of the customer how

    06:40 – we

    06:40 – understand the customer’s motivations

    06:43 – and what they’re trying to achieve

    06:44 – through

    06:45 – in this particular you know task

  • How OKRs work (and don’t work) for Product Teams

    How OKRs work (and don’t work) for Product Teams

    In a recent discussion with Patrick Collins from Zip Money, he revealed they replaced roadmapping with OKRs. At Contextual we’ve had several false starts with OKRs – so this deep-dive video is with OKR expert Sten Pittet of Tability.

    Sten asserts that one of the main things people get wrong is making objectives to quantitative and making results a proxy for projects.

    He said that Patrick nailed it by saying its OK to abandon a project during the 90-day period if it seems it will fail the Key Results you are seeking.

    The diagram below explains the hygiene that Sten recommends. By adding the “Projects” ring, it reduces the usual confusion about key results. (He acknowledges he stole this and enhanced from Simon Sinek’s Begin with Why).

    Specifically here the fixed-ness of Objectives and friction in changing Key Results. These are the stable business-centric goals that should NOT be schizophrenically changing after the last customer meeting or if the CEO has some genius new strategic lightbulb moment.

    Sten does a great job framing these 3 levels, starting with these statements:

    Related to impact you have on your customers.

    and

    Teams can double-down on projects that work

    Objectives

    The way you phrase the top-level objective has the potential to kill or inspire teams to launch projects to meet that objective – afterall people/teams naturally obsess over such a concise directive.

    Bad example: “integrate with Stripe” – only related to dev team – can’t help Sales/Marketing get on with their work. The Key Result is also very binary: “Ship or Not Ship”.

    Better Objective: Get Paid Customers. This empowers each team to flush out their own Projects:

    Product: find a way to charge them (that might still be Stripe but it is in concert with other possibilities and team Projects)

    Sales: what markets can I tackle?

    Marketing: what initiatives will drive growth?

    Support: how can we reduce churn or convert trial to paid?

    Moving down to Key Results –  these “really focuses the attention of people on what is important”. A sensible selection is not the binary Stripe result but Revenue. Suddenly things are quantitative and not binary – its more trackable.

    In the bad example: The Product team say “we really need to ship that integration”.

    In the good example:  Marketing can get great progress by surveying customers on purchase intent.  The big contrast here is that waiting 2 months for the Stripe integration won’t move the needle if there is NO purchase intent.

    So the Stripe integration is downgraded to a Project. If that project looks like it will fail or run over the 90 period – the better OKR helps teams ask: “how can we charge people today?”, “can we do it manually” etc.

    Bad OKRs can derail a company. Good OKRs align teams in achieving one big thing for the business.

    The evolution of teams getting used to using OKRs and becoming more “outcome driven” looks like the picture below.

    Projects then should change a lot, they are just “bets” on getting a better Key Result. He was impressed with Patrick’s comments:

    Teams are autonomous and they can double-down on what’s working – if a specific project doesn’t lead us to a better Key Result, then we just kill it.

    Sten thought this was a sign of a top team.

  • Scaling Product Teams

    Scaling Product Teams

    This video interview (below) is a section of a longer fireside with Patrick Collins, CPO of public company Zip (ASX:Z1P). There is 25 people in Product and 150 people in Engineering, so we dig into the way Zip is structuring given their explosive growth revolutionising how we think about payments.

    Zip organizes teams in triads of: Product Manager, Engineering Lead and Designer. They then have 12 “durable teams” that worked on fixed part of the product. So there is no rotation of teams according to a project, they are wedded to the part of the product they “own”.

    No BA’s or Project Managers

    The video starts with a discussion around the triad and what happens when PMs ask for extra team members such as Product Marketers, Business Analysts or Project Managers.

    Patrick’s contention is:  “I just haven’t seen any problems that the triad can’t solve.”

    He has a spicy response to requests for these extra roles: “I just think you’re doing your job”.

    Because hiring PMs is challenging given the high demand and lack of experience outside Silicon Valley – Patrick is bullish that these roles CAN become great PMs, but old habits/tools like Gantt charts have no value in the product-driven Zip culture.

    Scaling is splitting

    Patrick sees that durable teams – led by triads – is a scaleable structure that works from startup from public company.

    He reminded us that startups typically begin with: a hacker, a hustler and a designer. In other words the triad is often the basis of great startups because all the essential jobs can be done with these founders.

    The great challenge for startups is to control the propensity to split your focus by adding “New Features”: Patrick says: “if there’s not a strong overlap with the customers that you’re meeting on a daily basis and the problems that they face” then 

    No Roadmaps

    I was under the illusion that a public company – with all their investor expectations and oversight would need to have a predictable and accountable course of execution. I was wrong!

    “Why would I force my PMs to tell me what they’re going to do in six months when they’re they’re going to learn something tomorrow that might dramatically change their outlook on what they should do.”

    Instead, the company works from a very startup based ethos that 90 day OKRs map well from company strategy to sprint level execution and feature delivery.

    OKRs

    For the uninitiated, OKRs stand for Objectives and Key Results, you can read more here, here and here.

    “when I joined, the company was very focused on what initiative they were going to deliver, what feature they were going to deliver without kind of just answering those more fundamental Objective questions.”

    So the insight here is that Product Teams can always busy, but they need to have their efforts directed in harmony with the companies goals. The other insight that supports the “No Roadmap” principle is:

    • a Product Team can run an experiment
    • if that experiment is underperforming in achieving an OKR, then it can be abandoned.
    • another experiment can then be run with the intention meeting the OKR.

    This makes huge sense as a sanity check on any sprint scheduling process. Its not important to be busy – its important to get jobs done related to OKRs.

    Product Council

    The diagram above (sorry, no social distancing!) shows the ZIP approach to quarterly planning for the 12 durable Product Teams. Using the aforementioned OKRs, Product Teams present to a “Product Council” features from their backlog. The goal is to “lock-in” the sprints and features for 90 days that map directly to OKRs, Product Strategy and ultimately Company Strategy.

    Its an intelligent structure with feedback loops from Strategy to steering (Product Council) to prioritisation (Product Triad) to execution (Product teams of engineers, designers, QA etc).

    Below is the 10min snippet that delves into these topics – Patrick is crystal clear with nuggets that all teams can benefit from hearing.

    (sorry about some of the sync problems – WFH is really pushing neighbourhood network limits at times!)

    Transcript

    David Jones 25:09
    this probably speaks to a challenge too which is that a lot of people who might have been businessanalysts or project managers now see that the Holy Grail could be a Product role because product is now, you know, what, a decade ago, a product manager with somebody figured out the wording on the back of the Cornflakes packet. “Here’s where you call for consumer care”. Now, the product role is really a central part of the success with a customer and a real pivotal thing. So, a lot of people are running into that, but it sounds like what you’re saying is they’re bringing some baggage from their previous roles. Whereas really, they need to strip back and actually say, “What does the product really look like?” Is that what your are saying?

    Patrick Collins 25:53
    yeah, I’ve definitely noticed that with some of my team members at Zip, I think when I explained what a great product team looks like. I am fortunate, and the reason I joined Zip is that is already is a pretty strong product culture and it’s been set up pretty well. And I don’t feel like I’m trying to change something from a from a different kind of culture. But I definitely do notice, like, for instance, I’ve noticed that some PMS, talk to me often about why they need a BA on the team, or why they need an analyst dedicated or why they need a Product Marketer dedicated to them. And I resist, and we do end up in some pretty heated debates on it. But, I guess simplistically, I would say, I talked about that “product triad concept” of of an engineering lead, and a product manager and a designer. And I just haven’t seen any problems with that triad can’t solve. And so the idea that you would need to get dedicated folks from different roles to do that. To me I tend to use fairly harsh words like “I just think you’re doing your job”

    Patrick Collins 27:06
    Between those three people if you can’t figure that out, if you need an analyst to kind of understand the requirements of your platform I don’t know what you’re doing as a PM and tech-lead so and so yeah, I’ve had some I’ve had to kind of I think challenge some of that thinking for sure. That doesn’t mean that a strong BA can’t transition into a good PM role or a good project manager can’t transition into into being strong PM as well. Is there some baggage there?…..Potentially because I think in a modern product concept, product team approach that the shuffling of duties around between the team lead and the product manager is a little unconventional to the way you might see a traditional project team work.

    David Jones 28:01
    I think you said 25 people in product, 150 or so in engineering? So that’s one:seven-ish, I guess. Is that right? And anyway? Yeah. And then durable teams. So given that the product team has probably got a bunch of sort of like a management layer in there, does that mean you’ve got like 15 durable teams operating at the same time?

    Patrick Collins 28:28
    Yeah, it’s about right now about 12 durable teams. And in my product team is designers and UX. So there was some double up in the counting there. I think maybe give or take 15 dedicated Pac Managers. We’re all different of all different seniority levels and all different capabilities and skill sets as well. All product managers are not created equal.

    David Jones 28:52
    Well, as Monty Python used to say, That’s “bloody luxury”. You know, how do you how do you translate that back to like a smaller, smaller startup that’s perhaps got some product market fit. And this still sort of being dragged in many different directions. How would you give in your Fifth Finger experience? How would you think about durability and stuff like that; “tribes” or whatever. When you really when you really are wearing 40 different hats, you know,

    Patrick Collins 29:22
    I think it scales perfectly well, I think the idea of having…..when you think about a startup, normally you’ve got a hacker, a hustler and a designer, right? So, that’s not unconventional way to start a startup and sometimes the designer will be a freelancer or sometimes it’s (the founders are) a hacker and they’ve kind of got to go recruit someone to do this, the sales side. I think that is a very common organizing unit for a smaller business and it does scale really well. They just kind of keep splitting the problem down and scaling that up into a bigger company.

    David Jones 30:02
    It’s the surface area. So what happens is a start up, you’re supposed to have a smaller surface area, you’re kind of working on that nugget that really matters. And then you start to bolt on different things. So again, it comes back to focus. It’s like, if you’re gonna build this other project it’s gonna divide and conquer you. Right? Yeah. Okay. It’s always dangerous to work – So from a product perspective, particularly as a small team, considering new features, or considering new product lines is like one of the most dangerous things you can do.

    Patrick Collins 30:38
    It’s a challenge for sure. If it’s not if there’s not a strong overlap with either the customers that you’re meeting on a daily basis and the problems that they face. It’s a real danger to introduce a new problem into an existing team.

    David Jones 30:52
    Yeah. Okay, good. All right. So you’ve got you’ve got your teams. We had a chat on Sunday. And I said, What are your roadmaps look like? And you had a response…..

    Patrick Collins 31:06
    I said, “we don’t have roadmaps”, and you were shocked. Right?

    David Jones 31:11
    I was delighted. Go, yeah. Give us give us the good oil here.

    Patrick Collins 31:22
    I guess it goes back to that startup, like, if you were if you were four people in a room in a startup, and you were running really hot of a problem, would you build a roadmap for what you were doing? Wouldn’t right? You’d want to know really clearly what objectives you’re trying to resolve, what objectives you’re trying to accomplish and what problem you’re trying to solve. You’d be laser focused on trying to solve them. And you’d organize around that and the only time you might make a roadmap as if a VC asks you “what’s the plan ahead” and so you might go cobble one together on an ad hoc basis and do it. And so I see a scaled product organization no different. Why? Why would I force my PMs to tell me what they’re going to do in six months when they’re they’re going to learn something tomorrow that might dramatically change their outlook on what they should do. So, it’s an anathema to the idea that a product – so I guess my organizing principles, we just went through, we do quarterly product planning cycle, all 12 of those product teams presented yesterday to a group that I’ve organized called our Product Council and we predominantly focused around their objectives and key results (OKRs). So we had a lot of time debating what what this team should be trying to solve. I’m really proud to have gotten to that point over the course of a couple quarters because when I joined, the company was very focused on what initiative they were going to deliver, what feature they were going to deliver without kind of just answering those more fundamental Objective questions. And so, by focusing on OKRs (Objectives and Key Results), we’ve kind of forced the team to really understand what they want to get done by the end of June. And we forced the executives in the Product Council to align around that as well. And there was listed set of initiatives that they’d gone and done sizing to understand how they might deliver that there was a lot of research that had gone into it from a customer perspective as well about why that was good problem to solve. And each of those teams know that if they go to deliver a feature and they’re working on that feature, and as they test it with customers, they might only be halfway through design and development and testing the customers and realize it’s just not going to get them there. It’s not going to get them to their OKR. Then they have free autonomy to abandon that feature and move to the next most promising feature. And so it’s through that lens of crafting and curating a backlog of things that they’re going to work on and testing all the time to try to hit these objectives. That means that a roadmap feels fairly pointless. That doesn’t mean that I don’t have people in the company asking for it. And there have been some people asked for a roadmap and there certainly are features that our partners and customers need deadlines for to be able to integrate to. There are times where deadlines are critically important. But yeah, OKRs and backlogs is our primary organizing mechanism rather than roadmap.

    Patrick Collins 35:22
    And it is guided by a company strategy as well. So both the company strategy, there’s a product strategy. So there is other high level objectives and inputs that we’re considering. That helps guide the initiatives and the objectives that they’re trying to accomplish. I mentioned earlier that our mission is to become an everyday payments provider. That is an overarching “north-star” for us that does provide a pretty strong filter for the things that we consider to be valuable and important.