This week’s post is about our (PR)FAQ Database. We will talk about the idea, the present and how plan to evolve it in future.

This post is long due. This summer we launched a micro tool to help Product Managers create their own PRFAQs. (PR)FAQ Database is a living database of curated questions that Product Managers should ask themselves, internal stakeholders and customers to help them guide product development.

What is a PRFAQ?

A PRFAQ is document composed of 2 parts, a Press Release and a set of Frequently Asked Questions. It has drawn its inspiration from Amazon’s Working Backwards framework.

Working Backwards is a product development framework that focus on the customer and its necessities and works back from them, in order to create purposeful products. One of the main tools of Working Backwards is a PRFAQ: a mock press release of the end product and set of questions that would be asked by the customer (External FAQ) or by the organisation developing the product (Internal FAQ).

The (PR)FAQ Database helps with FAQ part of the PRFAQ with a set of questions designed to help define purposeful and profitable products.

Why did we decide to create a (PR)FAQ Database?

At the time we created the (PR)FAQ, I was working at a company that was not familiar with the concept. It was fairly easy to present the idea of being customer focused and to use PRFAQs to do so. My CPO at the time was also the CMO, he was happy to hear we would be getting a Press Release prior to development start. He was even happier to have the ability to guarantee that the development was Press Release worthy. This is often a challenge, product releases can take a long time and customer benefits are not always as sizeable as expected.

Making you first PRFAQ is not always an easy task, especially if the whole organisation is new to the process. Putting yourself in shoes of the customer often requires a great deal of discovery in advance. In addition, PRFAQs have a strong internal component which requires the product manager to also put themselves on the shoes of, architecture, development, operational and sales teams.

Figuring out which questions to ask depending on the product, product development category and internal department often requires experience and lateral thinking. I have experienced difficulties first hand when I was introduced to the PRFAQ process and when introducing it to a new team. In addition to help you taking the first steps, it is extremely useful to have a checklist of items not to forget anything during product development.

Did you do a PRFAQ of the (PR)FAQ Database?

No, there was enough value for me personally to keep my own curated list of PRFAQ questions. This was enough for me to carry on.

Architecture, Development and Shortcuts

(PR)FAQ Database is basically a searchable and filtrable list of questions. A public spreadsheet file would have similar functionality. We had that in mind when we conceived and developed the tool. Nevertheless, on our analysis, we found a few problems in going ahead with the public spreadsheet approach like Excel online or Google Sheets:

• Hard to collect analytics – We use Google Analytics and Hotjar on our blog. We would not be able to install these tools on a public spreadsheet tool. Validating hypothesis and collecting user insights and feedback would be hard;
• Poor SEO – We wanted to make the (PR)FAQ questions accessible for search engines;
• Not expansible – We wanted to add other features on top of just being just a filterable and searchable list.

In sum, we wanted something that could be evolved and have more functionality, while having in mind that a possible MVP for the tool had close to 0 development time.

To be able to deliver the tool quickly we had to come up with a simple architecture, with minimal operational management, simple development and be pretty much free resource-wise. Bear in mind that we have no funding for the site and I am the only “developer” (mind the quotes there, calling myself a developer is a big stretch these days).

On what concerns resources and infrastructure cost, backend and database would represent the biggest drains. If we could come up with an architecture that had neither of those, we would have big savings.

We were able to do this with the architecture depicted in the figure below:

We decided to use SQLite as the database. SQLite is a file based database that can be accessed with Javascript on the user’s browser. SQLite is used for a lot of phone apps and is very useful to keep personal data on the device. SQLite is not very efficient in situations where there’s big amounts of data on the database and it changes frequently. At the moment of writing this post, the (PR)FAQ Database has less then 200 records, its total size is just a few KBs (some images weight more). In addition, currently as it is a curated list of questions, it only changes when we update it. It is also not a problem to have all the database accessible to user, as that is the purpose of the (PR)FAQ Database anyway.

To avoid the need of doing backend code, we decided to manage the database access directly from React. We used react for the whole application, from views, to database querying and keeping url routes (for the filtering), all under a single application. React is also used to download the SQLite database to the customers browser.

In order to deliver the react application, we developed a very simple WordPress plugin using PHP application (which we basically copy pasted from past tools we developed for the blog). We used this great tutorial from Digital Ocean to get it done. The WordPress plugin renders the react app in pages that have a given shortcode.

add_shortcode( 'faq-database', function( $atts ) {
	faq_load_react_app();
  });

Finally, to be able to have one WordPress page managing multiple URLs we added a rewriting function in redirect.php:

function add_rewrite_rule( $regex, $query, $after = 'bottom' ) {
	global $wp_rewrite;
	$wp_rewrite->add_rule( $regex, $query, $after );
}
function prfaq_rewrite_rule() {
add_rewrite_rule('^prfaq-database\/(.*)\/?', 'index.php?page_id=504', 'top');
}
add_action('init', 'prfaq_rewrite_rule', 10, 0);

Using this architecture and keeping only core functionality features, allowed us to code the tools in a few weeks. The same time (if not less) then curating and categorising the list of questions, which is the main focus.

Analytics and Results

We launched (PR)FAQ Database less then 2 months ago, in a blog that was launched 7 months ago. At this point, our audience is tiny and consequently (PR)FAQ’s Database audience is also very small:

So far we got 168 page views across all (PR)FAQ Database URLs. These pageviews came from 68 unique users:

This tells us that the tool is far from viral, but the few users it got had a decent pages/users average. Given we are using Hotjar, we were able to record some of these user journeys:

Most of the users came to the page directly as we shared the page in a number of slack channels:

Even though search is not a big acquisition channel, we were able to rank well in a few interesting SEO queries like “prfaq generator” or “prfaq database”. These search terms have very few impressions currently, but they can pay off in the future:

Top queries	Clicks	Impressions	CTR	Position
prfaq generator	0	10	0%	1
prfaq database	0	14	0%	1.07
prfaq framework	0	1	0%	17
prfaqs	0	2	0%	25.5
prfaq	20	125	16%	31.32
prfaq amazon	0	3	0%	50.33
amazon prfaq	0	3	0%	52.67
prfaq examples	0	1	0%	55
amazon working backwards prfaq	0	1	0%	65

Special Guest

Despite the lukewarm reaction from the general public, we got a very special visitor Colin Bryar, co-author of Working Backwards. I was reading the book when I decided to create the tool, so I thought I could ask the authors for feedback. I contacted Colin on LinkedIn and he was kind enough to review the page and provide useful feedback. Thanks Bryar! Check his book: it is worth it!

Future

We have a number of features we want to implement to expand (PR)FAQ database: improving the ability to share questions, vote up/down question, user submitted questions, possible answer strategies to be linked to each question, among others.

However, before we commit to a roadmap to improve the tool, there are a couple of hypothesis we need to validate:

• Are product managers interested in using PRFAQs to manage their product development? For the users that are actually using the framework can a (PR)FAQ Database help them?
• If the question above is true, can we get a list of questions useful enough that product managers visit us when their working on their products?

As we will not spend any money promoting the tool, we will patiently keep collecting feedback and act to any momentum around the page. There is no point in committing resources to a tool that does not deliver value to users (other than me).

Let us know what you think on our public roadmap page ideashortcut.prodcamp.com! We are opened to feedback and suggestions.