Virtual Cabinet Bug Fixing Policy

Summary

Virtual Cabinet Support will help with workarounds and bug reporting.
Critical bugs will generally be fixed in the next release.
Non critical bugs will be scheduled according to a variety of considerations.

Raising a bug report

The Support team is eager and happy to help verify bugs — we take pride in it! Please open a support request in our support system providing as much information as possible about how to replicate the problem you are experiencing. We will replicate the bug to verify, then file the report for you. We'll also try to help you construct workarounds if they're possible.
Currently customers and 3rd party developers are unable to report bugs into our issue tracking system directly, though this is something we are keen to introduce.

How the Virtual Cabinet team approaches bug fixing

The Virtual Cabinet team take an agile approach to software development. Each release has a mixture of key bug fixes and new features.
If a bug is critical (production application down or major malfunction causing business revenue loss or high numbers of staff unable to perform their normal functions) then it will be fixed in the next release provided that:

The fix is technically feasible (i.e. it doesn't require a major architectural change).
It does not impact the quality or integrity of a product.

For non-critical bugs, the team prioritises the non-critical bug according to these factors:

How many of our supported configurations are affected by the problem.
Whether there is an effective workaround or patch.
How difficult the issue is to fix.
Whether many bugs in one area can be fixed at one time.

We give high priority consideration to security issues.

Virtual Cabinet Feature Request Policy

Summary

We gather feedback / product requests from a great number of sources
Votes for requests matter, but they are not the be all and end all
We try to group requests together to improve development velocity
We don't publicise our product roadmap, we use agile methods so it changes frequently and we care about meeting expectations
We are working hard on means to provide visibility into our top requested features, watch this space...

Q. How do you gather feedback for feature requests?

Feedback from our customers is an incredibly important part of our prioritization. Feedback comes from a variety of sources:

Customer Support: Our support team provides clear insights into the issues that are challenging for our customers, and which are generating the most calls to support.
Customer Contact: We get the chance to meet customers and hear their successes and challenges at conferences and road shows.
Customer Interviews: All sales, account, ops and product teams regularly meet customers. We don't just capture a list of features, but aim to understand our customers' goals and plans.
Field Experts: Our field experts provide insights into our real-world customer deployments, especially for customers at scale.
Early Adopter Feedback: When we release a new version to early adopters we want to know what they liked and disliked.
Evaluator Feedback: When someone new tries our product(s) we want to know what they liked and disliked.
Usage Data: Are our customers using the features we have developed?

The amount of feedback we receive is growing exponentially, so there is a lot of data to consider when prioritising a feature.

Q. How do I vote for a feature?

Currently the best way to request a feature is via your account manager or our support team, they will add your vote to an existing feature request or create a new one.

Q. Do votes matter?

Absolutely. Votes do matter, and the number of votes matter. The product management team looks at our top wishlist requests every time we look at our roadmap and upcoming release. It's important to note, however, that votes are not a trump card, and we don't translate votes directly into priority. This would ignore all the other sources of feedback we discuss above.

We look at feature requests and how to solve our customers' overall goals rather than just implementing what is described in the feature request. In many cases, we've created solutions (like presenting previous indexing information for documents returned from the portal) for something that wasn't a specific feature request, but that built the foundation to address a
number of issues (quicker indexing of signed docs, starting a task from signed docs, re-indexing signed docs).

Sometimes the cost of a new feature in terms of development effort is larger than the benefit of the feature. In many cases, we decide that the complexity of adding a feature may help one set of customers but hurt a much larger set of customers by making the product more complex. One of our goals for Virtual Cabinet / Portal is to make sure we are careful not to increase the complexity of the product (indeed we are simplifying the portal), but that we continue making the most powerful document management / portal solution for new users and administrators to adopt.

If a request has been around for a long time, if it has a large amount of votes, we still plan on resolving it, it might just take time, from months to years in some cases but we'll get there.
Sometimes, no matter how many votes a request has or how much overall feedback we have, we may decide to “Close” a feature request. It is always hard to say no, but we'd rather be direct if we have no intent to fix something. We want to be clear when we don't have any plans to satisfy a feature request and you'll soon have more visibility into our plans (read on).

Q. So how do you decide how to prioritize features?

In addition to all of our customer feedback, we have strategies, goals and a direction for our product. We also take the overall health of the product into consideration. For those top voted issues, we love to find ways to fit them into a broader strategy: What is the real customer goal that drives this set of related feature requests? We want to solve it holistically rather than on a one-off basis. A feature might be important to a small set of customers while other features might have a broader impact across all of our different customer groups and segments.

In grouping similar features together, we get higher velocity. We've seen this directly, when our team is motivated to deliver broad improvements with a big mission, that the team can deliver something incredibly exciting. An example is our recent revamp of the Office Addin user experience (an area where we've received a lot of feedback over the years from a broad set of customers).

Q. Why don’t you publish a feature roadmap for what you plan to implement?

We practice agile approaches to development, and as a result, we combine long term strategy with a continuous feedback cycle. While we do set out a strategy and long term plan internally, we don't build a backlog of the 1,000 user stories to accomplish that mission over the next 6, 12 or 18 months. Before we finished building that backlog it would have changed!

We also care passionately about setting, and meeting, any expectations and commitments we make - and when we make statements, in public forums or otherwise, we know our customers, partners, and ecosystem would begin to plan based on that data. So committing publicly to a fix version or general time frame is something we don't take lightly.

Q. So how do you decide which bugs to fix?

As mentioned above we review and triage bugs on a daily basis. As a general rule, we look at the overall impact of a bug on our customer base. How big is the impact? How many customers does it affect? Issues that are blockers for customers get the highest priority, and customer support helps us understand the number of customers who are being affected, as do customer votes on a bug. So the majority of our bug fix backlog is prioritised by customer impact.

But we still fix a number of smaller issues, that may not prevent use of Virtual Cabinet / Portal, but that hamper the experience, because we want to prevent the "death by 1000 paper cuts" that can come if we only budget for the critical and blocking issues.

Q. Is there anything you want to change or improve?

Absolutely!
Specifically in product management, we want to do a better job of providing visibility and communicating our intent for the top voted requests. Since we are implementing a number with each release, the "top" requests are always changing, and we want to make sure we give you a clearer picture of our intentions. We will be starting as soon as possible by providing access to the list of feature requests so that you can see how others are thinking, add your votes, and see when they get moved into planning and development.

Thanks to everyone who has asked about how we prioritise features here on the Virtual Cabinet team.