What is ...? Just check our glossary.
The world of product management is crowded with buzzwords and marketing talk. To add clarity, we created this dictionary of essential terms and their definitions which we frequently use in Productific.
Backlog
Backlog (Product)
Backlog Prioritization
Product Backlog Prioritization Techniques
Feature
Feature Request
Feature Request Tracking
Feature Voting
Product
Product Backlog
Product Team
Product Roadmap
Product Roadmap Voting
Product-Market Fit
Effective immediately, Productific discontinues support for log-in with Twitter. Twitter Inc. are forcing us to do this, API access has been quietly suspended.
We apologize to all users affected.
This suspension came without prior notice and without a reason provided. Appearently, it is part of a wave of suspensions that the app economy is seeing under the new Twitter leadership . See reports on Mashable, TechCrunch, and even on Twitter's developer community. It becomes obvious that either Twitter are planning to phase out their API access for small partners, or they are simply unable to maintain API operations under the new management.
To support the app economy and make it easier for others to research the issue, here comes some Developer Info.
The Twitter developer dashboard is showing our API asccess suspended along with a message "This App has violated Twitter Rules and policies. As a result, it can no longer be accessed. For assistance, submit a support ticket." One would expect that Twitter provide an option for creating a support ticket. But this is the new Twitter... the message comes with a link to https://help.twitter.com/forms/platform, which just redirects to the general Twitter support page, entirely unrelated to the developer platform. An option for support tickets is not available. The most reliable source of information seems to be this thread on the Twitter developer community.
Note that this is unrelated to the enforced plan upgrade accompanied by an email like the following, which can be fixed by a plan upgrade.
From: Twitter support@twitter.com
Subject: Application suspension notice
Date:
Hello,
This is a notice that your app **** has been suspended from accessing the Twitter API.
Please visit developer.twitter.com to sign up to our new Free, Basic or Enterprise access tiers.
More information can be found on our developer community forums.
Regards,
Twitter Developer Platform
Product teams consist of various roles and follow different structures. This article describes typical roles in a product team, typical structures of a product team, and helps you decide the best setup for your product team.
So, what are the roles covered in a Product Team? Most product teams work with a cross-functional setup where members have focus areas, fewer product teams work with a strict separation of tasks and concerts deploying strict team roles. While start-ups tend to use cross-function setups, large organizations in mature industries work with strict roles. The following roles can be covered in product teams.
Product Owner and Senior, Chief Product Owner
The product owner takes overall responsibility for a feature, process or product. This can be multiple persons each owning a certain part, or a chief owner taking overall responsibility.
Product Management
Product managers handle all sorts of management and assistive tasks related to managing a product. They can assist the product owner and typically report to a manager taking business responsibility. Product managers handle tasks like inbound/outbound communication and interface to other roles.
Product Design
Design, the process of creating things in a way they can best be used, is a core task of product teams. While visual design is usually covered by specialized visual designers, the actual product usage design is of highest interest and value to product teams. Product design strives to minimize usage friction, reduce click mileage, maximizes business benefit and strives for user happiness.
User Research
Understanding what users do, how they work, and what their real issues are is key to building a successful product.
Product Marketing
The process of bringing a product to the market requires understanding the market, the users and, most importantly, understanding the buyers. Product marketers help positioning the product and shaping the messaging to the market (marketing strategy). Likewise, product marketers also support customer development and customer success activities because customer focus is essential for product success.
Project and Program Management
Stuff needs to get done in a coordinated way. While some organizations use lean & scrum approaches, other product teams rely on project managers and sometimes even a program of various projects. Typical for product teams are hybrid approaches where operative tasks are handled in a scrum flow and lighthouse tasks have a project manager assigned, for example to manage cross-department dependencies.
Engineering & Product Development
Product engineering, which in many industries means product development, is a prominent stakeholder to product teams. While sometimes engineering is a part of the product team (think: micro service, agile squad), the engineering group usually is a separate organization that interacts with product teams. Naturally, engineering work posts real-life limits and needs too many product team responsibilities. Engineering investments need to be prioritized and engineering requirements are to be considered, there cannot be any product change without engineering.
Customer Success
Customer success managers help transitioning sales prospects to active product users. While delivering business benefits to customers, a long-term client relationship is established because these typically provide the highest benefit for both sides, buyer and vendor.
Product Analytics
Understanding the actual product usage is key to shaping a good product. Usually, the role of product analytics is a part time assignment in a product team and deals with the placement of in-product analytical tools.
Operations
Interfacing of product teams with product operations delivers insight into how products are typically operated. While in some industries this mainly relates to cost of operations (e.g. OPS in software as a service), it can relate to understanding the actual end user perspective in other industries (e.g. tools and machinery).
With the various roles covered by product teams being introduced we will now look at how product teams can actually be assembled. This describes their internal structure as well as the cooperation of multiple product teams in a large organization. The following structure patterns appear in product teams.
One Product Manager per Product
Deploying one product manager per product/product line/function is probably the most common product team pattern. This product manager coordinates the activities of market definition, marketing, sales forecasting, funding, budgeting, prioritizing investments into new features, long term roadmap planning, and product development. This comes with the obvious advantage of a single point of contact for all related activities. A disadvantage of this setup is the danger of local optimization where product managers optimize for their individual targets, losing sight of the big picture. Typically, this results in situations where a lack of development capacity is blamed for slow growth and short term deal success is overvalued versus long term strategy.
Product Team Matrix by Function
Product teams can cover activities by function: one person per task for inbound/outbound marketing, engineering, growth, business dev, user research, customer success, development, operations, and similar. This comes with the advantage of putting experts to the job such that all relevant tasks are covered on a cross-product team. A disadvantage is a loss of individual product focus, so the sweet spot of this matrix setup comes with product families and lines of products covered by a whole product team.
Product Squad (aka the Spotify model)
A specialized setup is known to be used at Spotify and Amazon. Amazon established the ‘two-pizza’ approach where, essentially, the number of people being seriously involved in a product can be fed by two pizzas in a team meeting. The Spotify model was first introduced to the public around 2012 when when Henrik Kniberg and Anders Ivarsson published their paper 'Scaling Agile @ Spotify', where they describe an approach to deploy an agile approach in a large organization. While their approach was, apparently, never fully implemented at Spotify - or at least evolved and changed by the time the paper became popular, the notion of product squads stuck and inspired may other organizations. The Spotify model is not a blueprint to copy from, it is rather a motivation and inpiration to give maximum autonomy and trust to local teams (squads). Knowing the Spotify model is beneficial when designing a product organization. The notion of a product squad including the related concepts of tribes, chapters and guilds are an ideal starting point for an ideation process that needs to meet the specific of your product/organization. Ideally, you use the Spotify model as an inspiration and develop your own approach to squads, tribes and guilds - this can give your organization an proud identity to work with.
By Customer *
In single-product companies (or few-product companies) it may make sense to organize product teams by customer. This can be by customer segment, by customer journey phase or sales cycle stage, or by any other meaningful metric (usage, performance, industry). These customer-centric product team setups are natural to B2C environments and B2B markets with a large audience or heterogeneous customer base. As an indicator for deploying a customer * product team setup just check other parts of the organization like sales and support - they may already be following this approach.
So, what's best?
Ultimately, there is no universal best approach for organizing a product team. What’s best for you depends on the above mentioned advantages/disadvantages, but also your willingness to delegate decision power to real product owners (versus using the assistive support of product managers) can make the difference when deciding for a product team setup. As a rule of thumb use a minimum approach where more communication overhead between various product managers roles is minimized by the team design. Less is more, small is beautiful, just keep it simple...
Users Plan: Team
We are launching https://featurevoting.page as an option to host product listings on a neutral domain.
A product listing can be served on this domain without any mention of Productific in the URL. This is part of the custom branding options and is contained in plan Start-Up and higher.
As a product manager, the ups and downs of using Jira are known to you: creating backlog items over and over again, ranking items, fighting with development over scope definitions and managing an excessive number of items and their dependencies are the unfortunate reality in the work of contemporary software product owners. While most of this makes sense, we want to introduce an improvement for product managers using Jira.
This article introduces the 50 shades of responsibilities of product managers, shortly introduces Jira and shows, how product managers can connect the customer perspective with a backlog managed in Jira .
Jira is made for developers, SCRUM masters and development teams. It is the industry standard tool for issue tracking, development backlog management, backlog linking and progress traceability. Development teams use Jira to organize their backlog, define development sprints, manage dependencies between various development items and keep development progress traceable. Usually, a team product owner defines and ranks backlog items. Sometimes, other stakeholders contribute to backlog item definition: non-development roles can post requirements to a team and also team-internal roles can contribute backlog items for team-internal needs like technical refactoring or re-design. The various members of a development team (developers and related roles) use Jira to "pull" their work items. This can be completely independent of other developers or in line with traditional focus areas of team members. The SCRUM master manages work in the team and uses Jira to track and sometimes assign items to team members. Jira is used by development teams to organize and manage their development items.
Jira can manage, track and relate the following items:
- development backlog items
- tasks and sub-tasks
- epics (e.g. user stories)
- issues/bugs
- changes and activities that need to be executed to support a backlog
Usually, product managers have particular interest in epics and development backlog items.
Product Managers are responsible for aligning customer and company needs with the capabilities of a product. This includes roll-in of new product requirements, roll-out of new product features, managing requirements of customers and company stakeholders and aligning them with the product packlog. Usually, product managers own the product backlog and its alignment with company strategy and development backlog.
In many organizations there is an overlap between the role of Product Manger vs. Project Manager, especially in organisations with a lack of separation between long term product/program management and development project management. Sometings product managers run operational tasks in project management, sometimes project managers act as product managers.
- Project managers are responsible for running in time, scope, budget, and possibly other operational KPIs.
- Product managers are responsible for aligning customer success, user engagement, sales, product growh and company strategy.
Likewise, there is significant overlap between the roles of Product Manager vs. Product Owner. By definition, depending on the industry and circumstances, both roles fulfill similar goals and tasks. Often, their work cannot be distinguished.
- Product Managers tend to be not responsible for actually running product growth, often limiting their work to roll-in, roll-out and customer management.
- Product Owners tend to take full responsibility for running product growth, owning progress of the product. While loaded with the full responsibility of taking product decissions, the before mentioned product management tasks may be outsorced to product manager roles supporting the owner.
Many flavors of product manager roles are existing, depending on the size and industry context of an organization the following specialized types of product managers exist.
- Senior Product Manager
A Senior Product Manager is responsible keeping it all together in a large organization with distributed roles and tasks of product management. He or she owns the long-term product strategy and business context, connects market analysis with sales with pricing with customer success, and also aligns with large client engangements. - Technical Product Manager
The Technical Product Manager is responsible for the technology of the product. He or she monitors technical innovation in the market and technological progress of the competition. - Product Marketing Manager
A Product Marketing Manager keeps an eye on the marketing plan, manages inbound/outbound market communication with SEM, SEO, social media and copywriting and owns the product's marketing plan and budget. - Development Team Product Owner
The Team Product Owner works with the development team and is responsible for rolling requirements into the development execution process and, likewise, for delivering. He or she is the link between development and product management, acting with complete ownership on the development.
While Jira is the go-to standard tool for development activities, it may be supplemented with other tools, most notably sheets or slide decks. Working in Jira makes perfect sense when interacting with development teams and actually dealing with development backlog, sprint planning, release planning or issue tracking.
In contrast, product managers are working with a zoo of tools. There is no de-facto industry standard tool for product managers. Often, the needs and traditions of departments dictate the tool choice and product managers are burdened with the task of keeping data synced between various tools.
Product managers use Jira when engaging and interacting with development teams. To PMs, Jira is the link with development planning and execution. While not owning the use of Jira, it is known to most product managers in the software industry because they interact with it on a frequent basis. The release scope, sprint scope, priorities and dependencies of various development items are visible and managed in Jira. Most often, it is the task of product managers to rank items or to provide additional content info so development items are described in detail and can be built. While team product owners and technical product owners tend to work a lot with Jira, senior/chief product owners will most likely only provide a few priorities and rankings to development backlog. Jira is a tool made for and owned by development activities.
In particular, while development backlog usually lives in Jira, customer feedback is usually collected in sheets or similar tools. Product owners sync customer priorities manually into Jira. To avoid such manual data transfer, which is error prone and repetitive, we at Productific plan to provide a customer feature voting integration with Jira. While the development team uses Jira to manage their development backlog, while the major product roadmap items are also present in Jira to support backlog management, a real feature voting perspective for customers is not included in standard Jira. A Jira integration with Productific will provide a direct link betwee customer priorities and backlog ranking.
Feature voting for Jira
Productific is a tool for feature voting, to prioritize a product backlog in line with customer needs. To connect feature voting with the power of Jira we plan to integrate Productific with Jira. To receive news about Productific's Jira integration, please subscribe to the feedback item on our own product roadmap.
First language available besides English: German 🎉
The web frontend displays in a language matching the visitor's browser config (aka i18n).
The following languages are available:
- English (en-*)
- German (de-*)
Multi-language support can be disabled in the dashboard to always display elements in language EN.
Please comment this idea to let us know which languages are relevant to your users
See related feature: Multiple language: content
As a product owner you probably have little time and lots of challenges to fight with. In sleepless nights you ask yourself the following: What is my backlog? How do I best prioritise it? A list of required tasks and their optimal order of execution are desirable. This article introduces what a product backlog is all about and shows common prioritisation techniques.
What are product backlog prioritization techniques?
Backlog prioritization techniques describe the approach to analyze and rank backlog items in order to decide which item to tackle first. Priorities are usually described by numbers to model the positive/negative impact of each item, making them comparable.
We compare the following methods:
What is a product backlog?
What is the best prioritization method?
- Ranking formulas help sorting a list of items, usually feature requests and other backlog entries.
- Matrix approaches benchmark backlog items in two dimensions to make an informed decision on benefit and disadvantage.
Matrix approaches
Value vs Cost Matrix
- Bread-and-butter approach, not considering it is a failure
- Straight forward, simple and easy to understand
- Drives towards easy wins
- Tends to ignore long term, strategic aspects
- Doesn’t work well when backlog items differ in orders of magnitude
Ranking formulas
ICE Scoring
- Good for ranking backlog items that compete for the same resources.
- Good for ranking backlog items when you have a reasonably good understanding of the item on cost and result.
- Highly subjective, items are rated by owner/team. No real user feedback involved.
- Not time stable, item ranking will largely depend on the timing of trending/pressuring topics.
RICE Scoring
- Includes user feedback data
- Includes individual users’ experience
- Time-consuming estimates
- Wear down when used repetitively
- Highly subjective when not based on user feedback data
Kano Model
- User perspective first: ranks backlog items by their customer value
- Ignores all non-user qualities like cost, risk and strategic fit
- Highly subjective when not based on real user feedback data
Stack Ranking
- Simple and straight forward
- Enforces clear priorities, less confusing compared to measure-driven techniques
- Does not support the actual determination of priorities, priorities are by management decision
- Priorities can change
MoSCoW Method
The MoSCoW prioritization model originates in agile software development. Developed by data scientist Dai Clegg in 1994, the MoSCoW model places items into the categories Must have, Should have, Could have and Won’t have. The term MoSCoW is derived from the first letters of these categories, the term is not related to Russia’s capital. The categories work as follows.
Must Have
The product/project must not ship without this. Failure to cover this item concludes to overall failure because you can’t deliver without. Typical Must Have items are core features, safety and legal requirements.
Should Have
Should Have features are important, but not notabsolutely necessary to the success of your product. They are painful to leave out and may have a negative impact on your product, but they can be delayed.
Could Have
Could Have items are desirable but less important than Should Have items. These are the typical nice-to-have items that can optimize a product further. Leaving them out or delaying them will cause less pain than a Should Have item.
Won’t Have
Won’t Have features are agreed to be non-critical by stakeholders and come with little or no payback. These items are kept in the backlog for later, they can even be dropped from the backlog.
- MoSCoW gives a good ranking matrix and helps managing a large backlog.
- Capability to align with the product strategy.
- Lack of rationale in determining the categories, largely subject to negotiation and judgement.
- Does not help to rank items with equal priority.
- Tends to favor new features over technical improvements.
Summary & Recommendation
Which Product Backlog Prioritisation Techniques is actually the best?
We do recommend to keep it simple and use any sort of cost vs. benefit flavor as the main decision driver. Cost estimations are highly depending on the actual organization, usually this is cost of development including a risk compensation. The estimation of benefit should be based on actual market and user data, ideally with a feature voting or customer feedback channel.
We adjusted our plans to better match the various types of product. This includes a better fit for owners running multiple small products and also a better fit for large-scale feedback listings.
New: per-product plans
From today on, all plans can be booked per product. That means you can list multiple products for free and choose a plan for each product, individually.
New: 20% off with annual billing
Annual billing is now available at a 20% discount.
Free plan
Everyone can now list up to three products on the Free plan. This helps spinning up new product ideas and testing market feedback. To reduce misuse for backlink-spamming, all outgoing links are now rel="nofollow". Owners must verify their email to list a product.
Improved tiers
We moved from 3 pricing tiers to 4 tiers. Plan Free remains available to everyone. Plans Start-Up, Growth and Business can now better match the various sizes and volumes of product listings. Also, organisations managing multiple products will see better flexibility in the new plans.
New tier limits will be applied after a grace period.
Check out the details on our pricing page. In case you need a custom plan please get in touch with us. Likewise, non-profits are highly welcome to message.
Existing purchases
Active subscriptions continue to bill at the old price, new pricing applies to newly purchased upgrades only. When a product listing exceeds the newly introduced tiers, an increased custom limit is applied. Nothing is taken away from existing subscriptions. Active Business subscriptions are automatically converted and upgraded to the new Business plans w/o additional billing.
How-To
CRM
Once you have a successful B2B product with customer numbers growing and your organisation scaling up, there will be a few high profile customers that stick out. These are standard-setting lighthouse companies in their industry that drive additional sales in their tailwind, early adopters in new market segments or simply XXL accounts driving a significant share of your revenue. These high profile customers are the ones you want to keep happy and engaged. Typically, they receive special caretaking and are subject to engagement initiatives.
Such initiatives are known by several names, each with slightly different focus and flavour:
- Customer Advisory Board
- Customer Advisory Council
- Customer Influencer Council
- Customer Influencer Group
- User Group
- Co-Innovation Initiative
- Co-Innovation Group
- Strategic Alliance
Common to all such groups is that they comprise of a small set of named participants who are, typically, users of the product. The product represents a business critical supply or service to them. Their vendor relations come with a high demand for innovation and stability. Members may be competitors to other members in their field of business.
Some initiatives engage with a rather large number of customers in a 'democratic' way: numbers, issues and priorities are exchanged openly in the group, transparency is highly valued. Members are typically users of the product. Their engagement is of operative nature, usability and feature/function are driving forces.
Other initiatives may be of rather private nature, driving co-innovation while protecting stakeholders' intellectual property. Information stays within the group. Members are typically senior executive in businesses using the product. Their engagement is of strategic nature, industry trends are driving forces.
Common to all such user groups, advisory councils and influencer boards is the information exchange on new product features and the alignment of future priorities. Members have a strong intendet to improve and strengthen the product. They are not in the group to negotiate prices, they are in the group to help you creating an even better version of the product.
The following tips help avoiding common mistakes when running a customer advisory board.
Tips for running an open user group
- Make participation easy
- Resist the temptation of hard selling
- Keep transparency up
- Appreciate any feedback
- Actively moderate toxic members, understand their reasoning
- Under-promise and over deliver, don't over-promise and under-deliver
Tips for running a private customer advisory board
- It can make sense to split initiatives by customer industry
- Watch out for members being competitors between them, openly address this. Make it clear: this group is not for collecting competitive intelligence.
- Nurture the engagement for the long term
- Stick to your strategy, resist being pulled off track by large deals
Tool support is of advantage to avoid endless manual communication work. Repetitive tasks like group management, voting and rollout can be supported by software.
Are you looking for a tool to run your user group or customer advisory council?
Productific will soon support user groups. For news and updates please check our feature listing for user groups and advisory boards.
Feedback listings can now be invite-only, open only to a selected set of users.
Step 1: Maintain a list of users that shall be able to access the feedback listing. Users are IDed via their email. A mass-edit function is available, emails can be uploaded via CSV.
Step 2: Invite these users to join the product listing.
Step 3: Users can log in via Google, Twitter, LinkedIn or SSO. Access is possible only when their email is on the access list. The product listing is hidden from anyone without access auth, not publicly visible.
Planning to run a private listing? Check out our tips for running a customer advisory board.
How-To
This article lists how Productific compares to other feature voting tools. Whether you look for alternatives to Productific or simply want to compare the tools, this list is a jump-start. Part 1 lists roadmap voting tools and shows how Productific is a good alternative (and where not), part 2 looks at replacing general purpose tools.
Intro
Product roadmap voting is used by agile companies to constantly collect market feedback and check if product vision meets market demand. New, attractive features can be submitted by users - after all, they best know what they need in order to work with the product.
Running product roadmap voting greatly simplifies the process of matching roadmap items to market demand. While B2B companies usually have a well established routine of running influencer councils with their biggest customers, roadmap voting tool support adds another level of insight and agility.
The market is flooded with roadmap tools. Each serves a slightly different purpose and may be a better or not so good fit for your needs. We compared Productific to feature voting tools available in the market and also some general purpose tools - as product managers are still tempted to use Excel or Trello for roadmap prioritization and customer feedback.
The following tool comparisons are available:
Part 1: Roadmap Voting Tools
Part 2: General Purpose Tools
Survmetrics (roadmap feedback)
How-to: choosing the right feature voting tool
Your product roadmap is loaded with ideas and now it’s time to decide what to build next. All stakeholders are happily anticipating their favourite feature to make it into the product - you need to take tough decisions. Does that sound familiar?
Productific helps you choose the best ideas from your roadmap by prioritizing according to customer feedback. Identifying the most promising ideas is automated, product owners can take informed decisions based on user feedback data. A product backlog can be prioritized in four simple steps.
Step One To choose the best you describe your product improvement or development request on an idea feedback page. Do that for all your relevant ideas such that the backlog is listed for feedback on a product influencer board.
Step Two Publish your ideas. Pass the URL of your product influencer board to users and customers, along with your product-related communication. You can find via e-mail newsletter, Facebook or Twitter — anything will so fine.
Step Three Collect customer feedback. You can engage via voting, subscriptions, comments or pre-orders. Ideas can stay open for feedback for a long time to collect significant input.
Step Four Use data to decide. By collecting user feedback Productific will automatically assign priorities to the backlog listed. You can choose what to build next from a prioritized backlog, based on customer data.
By listing all your product improvements and feature ideas you can analyze how they rank on user feedback. The feedback data represents user sentiment towards the ideas listed and identifies your most popular ideas.
Usually, as a product manager you will have a feature backlog listed somewhere — but you need to assign priorities to it. Productific turns your list of improvement ideas into a prioritized backlog, ranked by user echo. Once user voting is available you choose the best ideas to build according to popularity, customer value and development cost. Various backlog prioritization techniques are available to accomodate for all perspectives.
You can and should keep your customers engaged after they provided feedback. Productific provides a roadmap view for features under development and a changelog view for features available. Also outbound messaging to customers can be done in Productific.
Changelog info can be embedded as a widget on your website or in your product.
Entries (product news) are based on Productific listings and can be shown in-app as "news", "release notes", "what's new" or anything similar.
Prototype screenshots, custom design:
This article describes how to embed a changelog in-product with Productific. We explain what a changelog is used for, what should be shown in a changelog and how to embedd a changelog into your product/website using Productific. A <TL;DR> summary is available in our changelog widget JSFiddle.
So, what is a changelog? A changelog is a list of product news made for users and customers. A changelog keeps customers in the loop about your product and shows users what’s new. It drives awareness for new features and increases user engagement.
Why do I need a changelog? Your product is improving continuously and evolving month over month. Lots of work and effort go into product development. Usually this is the majority of investments in product companies - so never let your users miss product updates: show a changelog to engage users on the new stuff. A well maintained product changelog increases user engagement and product awareness. By embedding a changelog, anyone working with the the product can see the latest enhancements and easily navigate to get details about new features. Once users see the news they can try it out.
How do I use the changelog widget? The changelog widget can be added to any HTML-based product. In particular, to websites and web apps. Including the widget takes only three quick steps and can be done in 2 minutes. Using the widget, product news are listed in the order of availability, newest first, and users can navigate to display details about each new feature.
Step 1: Add the following tag in the HTML of your product. This will import Productific's changelog.
<script src="https://productific.com/cdn/productific-changelog.js"></script>
Step 2: Place this HTML div right where you want your product news to appear.
<div id="productific-changelog"></div>
For example, at Productific we show our own product news as a card element with shadow:
<div id="productific-changelog" class="mb-4 card shadow rounded"></div>
Step 3: Include the following javascript call. This function will fetch your product's changelog entries and render them into the element placed in step 3.
Productific_getChangelog('MY_PRODUCT', new Date("2019-01-01"), $userId, config, onDone, debug);
The parameters are:
- 'MY_PRODUCT'
The identifier of your product, just check your product's feedback URL: it's the part after the @, usually resembling the product name. - new (Date"2019-01-01")
The start date for product news to show in the widget, only features with an availability date after this date are shown. Use this date to display only the latest product news to your users. - $userId
An identifier for the current user. Can be a technical ID, email or hash. We use this to remember hidden items which we will not display to this user again. In case $userId is not provided we'll use a cookie to identify the user. - config
Optional, for adding custom styling. See step 4. Just pass null to use the branding configured for your product listing. - onDone
Callback function receiving a JSON value with the html of the changelog and number of entries. - debug
Pass value true to enable talkative log output.
function onDone(changelog) {
if (changelog)
console.log('changelog by Productific: showing ' + changelog.count + ' entries');
else
console.error('changelog by Productific: something went wrong');
}Step 4 (optional): Use the optional config parameter to style the changelog widget according to your needs. While the default widget will apply CSS styles according to the styling of your product listing on Productific, the following classes can be added to modify and customize this default styling.
var config = {
headerClass: '...',
itemClass: '...',
linkClass: '...',
buttonClass: '...',
footerClass: '...',
buttonHTML: '✕'
}Example: at Productific we include our own product news using these Bootstrap-based classes
var config = { headerClass: 'p-2 text-center card-header ', // card header itemClass: 'my-0 d-flex ', // flex-box linkClass: 'm-2 text-left muted-link flex-grow-1 ', // link w/o any deco buttonClass: 'm-2 pmaasColorLightGrey align-self-center ', // hide-button in grey footerClass: 'p-2 muted-link-a' // link w/o any deco
//buttonHTML: '✕' // default button ✕ is ok here
}
You can use existing CSS classes or create new styles for the changelog widget.
A website changelog template is available on the example changelog widget on JSFiddle.
Please also see our tips for writing a good changelog.
You are a product manager, owner, app developer or marketing manager of a product and want to spread the word about the latest product enhancements. This article is for you: we explain how to maintain a good changelog.
What is a changelog?
A new feature was ideated, designed, built and shipped - now users need to know about it. A changelog does just that: a changelog is a list of product enhancements and product news. Typically sorted by availability date (latest first) each entry informs users about an enhancement. This can be new features, additional documentation, better integration, or the removal of major constraints or bugs.
Who writes a changelog?
Anyone with product responsibility or ownership should maintain a changelog. Typically, this is a:
- Product owner
- Product manager
- Developer
or a related role/group like
- Product analyst
- Marketing manager
- Customer success
- Sales
- Documentation
- Support
Who reads a changelog?
A changelog is made for two types of consumers:
- Existing users of the product. People currently using your product can easily be engaged in new enhancements. During their daily usage they're not always searching for new features, especially in SaaS where product updates are shipped without notice to users. A changelog entry points users to new functionality, ideally the product news is embedded in-product to be noticed by users en-passent. Actively engaging users in new features is of great benefit. All the investments are paid for, all the work of building it has been done. Now it's time to foster usage of this feature to draw benefit from the investment: happier users, increased customer benefit and greater competitive positioning for your product. After all, the more benefit your customers get from the product the more likely the will keep paying for it. Active changelog communication is essential to engage existing users.
- New customers, like sales leads, new deals or any other interested candidate. A changelog can activate existing sales leads when their "deal breaker" is added to the product. Product news can attract prospects from new markets and industries when appropriately published. After all, change log content increases your search engine discoverability because it can be written in non-marketing, straight forward product language. People in the information and discovery phases of their purchasing desission can be attracted by professional changelog content.
Where is a changelog placed?
A changelog can be placed in-product, with embedded product news or a changelog widget. This best addresses existing users.
A changelog can also be published publicly, on a changelog page or via release notes distribution. This best addresses new customers, supporting your marketing and sales efforts.
Ideally, changelog info multi channel, reaching existing users and new customers.
What makes a good changelog entry?
- Changelog content is not marketing content. Users expect a precise description in the changelog item. They want to understand what's written. Entries do not need to be of excessive length or size, for example they can simply point to where the new feature is available and what it does.
- The title is short and on the spot. Especially in-product changelog/news should carry a short and crisp title. Avoid clickbait, just describe the new feature/function like you would talk to another user of the product.
- The description contains text that introduces the new feature to existing users. A screenshot or sketch can work wonders... whatever works best for you.
- Avoid bug fixes. Mention only major bug fixes, avoid them for news placed in-product. Keep a separate log for bug fixes in case this is really required for your product, usually a ticked system will be of better service for chasing bugs.
- Be honest, don't over-promise because it will kick back when interested users are disappointed after exploring the new feature.
- Focus on customer value. Tell the user what gets better and in particular how the new feature creates value. Think of money, time, savings or anything quantifiable.
- Provide examples. When introducing new features off the beaten path provide examples to guide your users towards adoption. Use "you can use this to...", "get better... with..." or "increase your... by..." to drive adoption of the new feature.
Following these tips will help writing a good changelog and publishing product news that drive adoption. Like with every rule there are exceptions: of course you can to any viral marketing stunt that helps pushing new features to the public. You can run dedicated press releases and marketing campaigns. Though reliable, high quality changelog information will be appreciated by all users, existing and new. With Productific you can publish such a changelog, on dedicated pages and placed inside your product via embeddable widget.
Feature requests come in once a product has an active user base. Engaged users will request new features to improve the product for their needs - sending valuable fresh ideas.
But not all ideas are good for your product and cannot be converted to new product features. Some are hindered by limited dev capacity and others can conflict your product strategy. Requests should never be responded to with a simple 'no' or decline. Managing feature requests graciously without saying 'No' to customers is not rocket science.
This is how we manage our own feature requests at Productific. Instead of saying 'no' we follow a three-step-process to nurture user relations for the long term.
- We seek clarity on what the request is about. Sometimes what's being asked for is not the real intent of the user. Understand the underlying pain/issue is important to digest feedback.
- We let the user know what we do with his/her feedback. Nothing is more discouraging than the feeling of being ignored.
- We acknowledge the feedback and ask for more.
Feature requests often fit one of the following patterns. Knowing the patterns helps engaging with active users and efficiently communicate with users 1-to-1.
Feature already exists
The requested feature already exists in a similar way. Point the requesting user to the existing feature and check it really solves the pain.
Feature already up for feedback
The requested feature is already listed for voting to best understand priorities for all users. Encourage the requesting user to vote and subscribe for news.
Bug
The requested feature is considered to be a bug which will be fixed in the next update, as soon as possible.
Up for voting
The requested feature is understood and appreciated as a desirable improvement to the product. However, due to development capacity constraints it needs to be prioritised Betsy other much desired product enhancements. In order to prioritize for a broad user base, you gather additional user feedback by running user voting. The request is listed for feature voting.
Clarity
The requested featureis not entirely clear from the submitted info. Seek additional feedback and ask for more details. Ask for reasons, understand the actual pain and desired improvement.
Strategy
The requested feature is understood, the user value is clear. However, it does not match with the product vision. You want the product to move in another direction and feel this requested feature does not support that direction. Provide reasoning that the requesting user accepts and provide alternatives. Alternatives can range from tips to avoid the original pain another way, all the way to suggesting supplemental tools to help the requesting user.
In all cases make sure to thank the use for the feedback. Express your appreciation for the effort taken and encourage additional feedback for the future. Remember: users send requests because they like your product and want to improve. Doing this, they're in the same boat as you, the owner of the product. Encourage and appreciate their work.
To save your time, Productific provides tool support for managing incoming requests without saying 'no' to customers. Instead of openly rejecting an idea sent by customers, Productific helps engaging with users based on the above patterns. Email templates are available in the dashboard for responding to user requests, one click right at your fingertips.
How-To