Product Managers: Release your inner CIO!

When people ask me what I do I say “in one word: definition.” Certainly not in isolation, its representing business, technology and user needs into a cohesive product strategy.

People in our field are usually fastidious about organisation. For example, I’ve migrated my Palm OS address book from high school on from one device to the next and even have it to this day — still with my high school contacts (Justin do you still have the same number?)

Getting organised with product definition is important because once the product is defined — it becomes the centre of your company’s universe. Literally everything, competitive analysis, support issues, sales opportunities, market research, need to be cross referenced into your product definition.

I thought I’d take a minute to share how I organise product definition and cross reference it to everything else.

BTW, this article doesn’t address the process where product moves into project (delivery). If you think about it in accounting terms, its more the balance sheet view here than the cash flow. Also I’ll start the hierarchy of data management at the product level, not the portfolio level.

Jira and Confluence (cloud) are tried and true tools for PdMs. I use them to hold core definition — not because I love the tools themselves (I find them a bit ‘engineery’), but because our devs/BAs use Jira and Confluence. I did use Aha for a while (and loved it) but the one problem was that when a dev or BA wanted to find something, they might do a search in Jira/Confluence and might miss what my team had defined. I’d like the definition to live on and be “findable” in the future.

Features

Within the product the highest level of definition I have is a feature. It’s an umbrella name for a whole realm of functionality. For example “registration” or “billing and subscriptions.” Features then contain capabilities / use cases / user stories. I don’t think it matters hugely what these are. The point is they are succinct deliverables and need to be formatted in a way that’s preferable / consumable for developers. We keep our “feature brief” documents in confluence. They are timeless and contain user cases that have been delivered, are in delivery and may be delivered. Having deliverables under features lets a PdM show phasing — we might deliver a bit of this feature now, some later and the extravagant stuff maybe never. The features and use case can be visualised as a tree with each node being red / orange / green to indicate future / in concepting or delivery / delivered. I will cherry pick use cases from my “tree” into my backlog and meet with the team regularly to scope the next parcel of work for the product.

Figuring out what to put in Jira vs Confluence

I use Jira for “databasey” stuff and confluence for content. Confluence has some pseudo database capability but it’s really just for things like tables of contents and it doesn’t let you map data to other systems. For each feature and use case, I create a complementary issue in Jira. Jira generates the ID for that feature or use case and the Jira ID becomes the key that I use to reconcile the product definition against other systems. Here’s an example of how I structure the data:

So a confluence page will link to the Jira Id (and show the status of the deliverable), the Jira issue will link to confluence. Confluence contains the content, the in/out of scope, the details, the what, the ‘why’, the process flows, etc. The Jira use cases are what get delivered (changing to status ‘delivered’) but the confluence content is product definition that will remain referenceable indefinitely. Jira also contains the fields I need to move data and generate reports.

Start moving your data around

Not all features / use cases need to be reconciled externally. So we flag the ones that do and then use Zapier to push features / use cases to a special “Features” object we’ve created in Salesforce. In Saleforce I’ve created a master detail panel in the Opportunities so account managers can select what current and upcoming features the opportunities need.

We store competitors in Salesforce and can use the same feature mapping to visualise whether competitors have our feature or not.

This gets us good reporting. I use Fivetran to transport the data out of Salesforce and Jira and into a Postgres database on AWS. Spinning up a Postgres database is a cheap way of data warehousing (Redshift runs on Postgres anyway).

Report on the data

Once the data is in AWS, I can hook up a web-based BI tool. I’ve tried mode and a few others, but I like Periscope the best because I can join the data across databases using SQL and then mess with the data (do pivots, charts, etc).

One report we’ve been able to do is opportunity revenue against undelivered features. The intel we get from this is limited since we’re already profiling against delivered functionality but the extra needs those prospects have can help fine tune prioritisation (e.g. this is a big $ opportunity and they need this one feature thats a bit further out, lets bring it in).

This simple BI setup helps status reporting too. Since all the Jira data is brought in, project status reports (beyond the burndown Jira gives you) can be generated without any extra fuss.

Reference integrations and interfaces to core

One final thing we do to help keep things organised is keep our core API definition in one tree and then reference products and integrations back to that. So for example for integrations our platform might support these capabilities “user can provision a new account on partner system” or “user can connect an existing account on partner system.” That is defined in one place but then when you go to the page that defines that integration, the page in confluence will do a JQL select in Jira and list out all the capabilities that are supported in that integration. Coming from an engineering background myself it keeps core platform definition DRY ;)

When I see all of my product definition propagating out like a well oiled clock — it makes me feel all warm inside.

How do you manage your product data — let me know!