Expectations from InCred Product Managers

Why?
As the team scales, communication complexity scales combinatorially (NC2). So it’s important to
invest upfront in the right mechanisms that allow freedom to individuals to operate and run as
fast as they can, while also ensuring minimum baseline operating discipline in how we do things
as a team.

Our Philosophy1 of how we do work

(For full list of product competencies see
https://docs.google.com/document/d/1Z0KK2AHn2qZ_E2cMnyJVFU4aZAJc46CQ5wQ42vl3FvY
/edit)

1. People over process

Results and outcomes matter, not a perfect process. We deliver results above all.
However, good intentions alone don’t work. See #6

2. Speed matters in business

We empower our team members to run w/o needing permission as long as it’s an easily
reversible decision (a “two way door”). Irreversible decisions need alignment and should be
carefully thought through (a “one way door”). Most decisions are reversible and don’t need
extensive analysis.

3. We exhibit “extreme ownership”

We act as owners and relentlessly drive the ball forward, while recognising that “owning !=
doing”

4. We sweat the details

MVP is not permission to ship crap. It is a carefully designed experiment designed to test
a specific hypothesis. It’s a “bullet” that is seeking to find the target outcome. Once
found, then we double down and unload a cannonball to hit the same target.

5. We write a lot to create and drive clarity across the org - using data driven truth
seeking as our alignment device
We write to evaluate ideas, to analyze root causes of issues, to provide weekly and
monthly business updates, to provide context on vision and roadmap, and Jira tickets for
engineering to consume so they have context on what we are trying to do. We also use it
as a device to efficiently onboard and hand over projects to new hires. So, our
documents at any point in time reflect current truth and are kept as up to date as is

1
See Product Team Competencies/Values Alignment for a full list of competencies we expect from our PM’s
 reasonable. Finally, several ideas explored in this manner, but that don’t make it to
production are a feature of this process and not a bug.

6. Good intentions alone don’t work. Good mechanisms do

We believe that “discipline = freedom” and invest in mechanisms to produce repeatable
outputs given a series of inputs.

7. For people managers - we trust, but verify

We trust our direct reports to do the right thing and work hard to empower them with 2 way
doors. But we dive deep to audit and make sure the data matches up to anecdotes.

Our “mechanisms” - the nearly 10 commandments

1. Regularly talk to your peers - 1:1 - across sales, engineering, operations, risk analytics,
RCU. Sniff out problems early and DO NOT assume alignment. Build strong
relationships based on trust.
2. Write PRFAQs2 to evaluate big ideas, to discuss and drive consensus and collaboration.
Keep them always updated and readable.
3. 6 Pagers for business reviews, for commentary and for correction of errors/elimination of
defects at the root cause
4. Link PRFAQs where available to the JIRA Epic
5. All EPICs should contain the clear “north star” we will use to decide victory and the
hypothesis being tested
6. All Epics should have a Wikipedia like “backbone” linking and providing structure to the
stories within an epic. Following the above structure allows anyone to double click to
PRFAQ —> Epic —> stories and the other way around as well
7. No releases affecting the customer or sales experience goes live without the customer
experience being documented in git (productdocs.incred.com) and without UAT / demo
to teams and always preferably are Feature Gated
8. We use JIRA roadmaps that are kept up to date by PMs and APMs and ALWAYS
available
9. 6 monthly operating plans are prepared and kept up to date by Sr. PMs with once a
month presentations to business teams

PRFAQs, Jira epics and stories are all seeking to answer 5 (+1)
questions:
- Who is the customer
- What’s the problem statement (or opportunity)
- What’s the most important customer benefit

2
Press Release + FAQs. Use good judgment on when needed. See Appendix I for how to write one
 - What data do we have to prove that the customer wants this
- What does the end customer experience look like
- (+1) What does our execution sequence or GTM look like

PRFAQ and 6 pager templates and writing tips

How to write a PR FAQ and why does it work?
1. Write it in a neutral tone like a journalist announcing it to customers would
2. Make it customer focused vs. internally focused (what’s the benefit for the customer vs. for
InCred)
3. Use “Oprah speak” - No buzz words, 3 letter acronyms etc. Explain like you would to a lay
person in very simple language
4. Suggested structure below
- Paragraph 1 - Summarize the current problem customers are facing and your unique
solution to it. Assume no one will read beyond paragraph 1. So make it good
- Paragraph 2 - Summarize the problem statement in detail
- Paragraph 3 - What is our solution and how and why does it solve the problem as well
as how it differs from other solutions in the market
- Paragraph 4- Internal business head quote
- Paragraph 5 - Customer quote (who has experienced the product)

6 Pager template 6PagerOnWhy6Pager

An internal PRFAQ on launching green channel:

https://docs.google.com/document/d/18N3KO2iA6k5qTUkgu5i_-taMoH_CN3jlaAMYDcSjfEA/edit

Epic and story structure - a template and some suggested guidelines

A template for a good epic and story structure
1. The value add for the business should clearly come through. Why are we doing this?
2. How will we measure victory? By doing this, X will move by Y% from Z to A
3. Focus on the what and the why. Leave the “how” to engineering/co-create
4. Clear in depth acceptance criteria needs to be written
5. Every story should be atomic3
6. Structure the “parent” story/Epic like a wikipedia article. Every big chunk becomes another story to be
hyperlinked to the parent story
7. NFR testing checklist where applicable should be checked and signed off before go live

Some writing guidelines to write better

Use time efficiently. Make sentences clear and concise

3
In terms of user stories, making them 'atomic' means that each user story cannot be broken down into
a smaller amount of functionality. Estimation of user stories improves when stories are at their smallest
 - Use less than 30 words per sentence.
- Use subject-verb-object 4sentences with ‘doers’ and ‘actions’
- Avoid ‘clutter’ words and phrases

Bad example Better

due to the fact that Because

totally lacked the ability to could not

With the possible exception of Except

Until such time as Until

For the purpose of For

Be objective: avoid adjectives and adverbs. Replace adjectives with data.

- Adjectives are imprecise and don’t contribute to making a decision.

- We should as a group react negatively to buzzwords and qualifications made without data.

Subjective (bad example) Objective (better)

We made the application much faster we reduced XYZ API’s trailing 90-day latency
from 10ms to 1ms

This will make the endeavour extremely This will increase output by 5%
successful

Eliminate weasel words

Weasel words are vague and create the impression of meaning. DO NOT USE THEM

nearly all customers 87% of customers who contacted us

significantly better. +25 basis points (bps)

more examples of weasel words: would help the solution, might bring clarity, should result in benefits,
significantly better, arguably the best

If you are asked a question, reply with one of 4 answers

4
English is an analytic language and falls in the 42% proportion of the world’s languages where the
subject-verb-object order makes sense. Use it.
 Yes

No

A number

I don’t know (but I will follow up when I do)

Appendix
Additional reading material
● Product management frameworks by Shreyas Doshi
● What is Product Management - an interesting no holds barred tweetstorm by Jason
Evanish