Responding to Change: Introducing MVPs

Editor’s note: Interested in the Engineering team and what they get up to? They’ve got their own blog over at engineering.brandwatch.com. Head over there for insights into what makes them tick, what they’re working on and other developments behind the scenes.

---

The Engineering team here at Brandwatch have an ever-growing wishlist of features and functionality to add to our platform and products.

It can be difficult to decide where to allocate development time, so we’re continually exploring new ways to gauge what adds the most value for our users.

---

Introducing MVPs

One concept that we’re currently adopting is to initially create features as Minimum Viable Products, or MVPs. Wikipedia succinctly summarises the concept as:

“In product development, the minimum viable product (MVP) is a strategy used for fast market testing of a product or product feature to gain quantitative or qualitative feedback. The term was coined by Frank Robinson and popularized by Eric Ries for web applications. It may also involve carrying out market analysis beforehand.”

At Brandwatch we’re trying exactly that – focussing on getting the kernel of a given idea researched, coded up and then released to a small subset of users so we can learn what works and what doesn’t.

Then we can iterate quickly towards the best solution, or indeed in some cases go back to the drawing board and start over.

---

The MVP process

When we decide to commit to implementing a new feature, the team’s Product Owner sketches out a list of user stories that describe the functionality and puts them into the team’s Product Backlog.

Then we get a few team members together to ‘groom’ the backlog, an exercise where we flesh out user stories so we all understand them, discuss any technical hurdles that we can foresee, and perhaps add acceptance criteria that governs whether a given story is complete or not.

We use SCRUM in our teams, and this is a great match for the MVP mindset. We’re able to plan 2 weeks worth of work (a “sprint”) from the product backlog, build it, then demo it to our internal stakeholders and iterate onwards from there.

At a given point, generally several sprints in, we have something implemented that conceptually proves the feature that we want to release, with any major technical questions answered and challenges overcome.

The feature is generally missing a lot of functionality that we know that we need to add, but still exists as a solid barebones implementation that can act as a foundation for research and further development.

At that point we can release the feature as an MVP (or Alpha).

We select a very small set of users that have an interest in the feature and enable it for them. We can then get feedback from these users directly, as well as via our analytics integration with Keen.IO and determine where to take the feature next.

As we iterate further on the feature we take it to a beta release to a wider group of users, before formally launching it to everyone, hopefully in a much better shape and with a bigger impact.

---

In summary

We’re hoping that the MVP process will help us to deliver features to our users more quickly, with more of a focus on what you want rather than what we think you want. “Responding to change over following a plan”, after all, is one of the fundamental tenets of the Agile Manifesto, and a principle that successful modern development teams should follow.

If you’re interested in getting involved in alpha or beta use of new Brandwatch features we’d love to hear from you! Drop us an email at [email protected] or tweet us at @Brandwatch!

---

[cta_button title=”We’re Hiring” text=”We’re Hiring” target=”https://www.brandwatch.com/careers/”]