Evolving and building products

As is the case with many tech companies, VidMob’s product suite has grown over the years to include products and feature sets in varying stages of development.

Our “oldest” (in startup terms!) has been out in the wild for over 4 years, while our “youngest,” the Creative Intelligence tool, has been out of beta for a little under a year now. This difference in lifecycle stage has significant implications on how we as a product team approach feature development and prioritization.

Evolving products

Our approach to evolving an existing product is grounded in specific user feedback. The goal of this type of development should be improvement — whether that is improving existing features and user flows or improving by adding an entirely new feature to an “old” product.

In either case, it starts by listening to our clients through user testing. The results of this guide our team to the biggest problems to solve for our users. It can be painful to watch, but we very quickly learn which parts of our platform aren’t quite as intuitive as we thought they were. We start from the top with those pain points that affect the most important jobs-to-be-done, and our roadmap basically writes itself.

Defining scope

Before we start building though, it is helpful to gain an understanding of where the product has been — that is, it’s important to know the decisions that contributed to how the product behaves today, and why those decisions were made in the first place.

This knowledge forms the basis for scope constraints, and helps guide the conversation around what is and isn’t feasible and what should and should not be touched. It can also serve as a reminder of things that were tried in the past and subsequently changed or abandoned, so we can automatically exclude those ideas.

Building products

Once we’ve decided on a feature or feature set we want to improve, know the technical constraints and the problem we’re trying to solve, then it’s time to dive in. The key here is that we allow ourselves to take our time, relatively speaking. There is no fire burning — everything still works, it could just be better, so in the grand scheme of tech development, we have the luxury of acting a little more deliberately.

Our process for this type of development typically begins with a design thinking workshop. We gather stakeholders and representatives from each leg of Tripod (Product, Design, Engineering) for a several-hour session where we ideate as many ways as we can to improve the user experience for that feature set. This requires tapping into our empathy gene, truly putting ourselves in the shoes of our users, and understanding their needs.

Based on the output from this session, we typically go through several rounds of mid-fidelity prototypes and testing, ultimately narrowing in on final designs and requirements after 2–3 iterations. For us, this type of project leans more towards the Waterfall methodology than Agile, as requirements are rarely changed mid-build and we are focused on finesse.

Evolving an existing feature set

Outputs page

Problem: Over the past year, client projects became a lot more complicated as the average number of video outputs per engagement steadily increased.

However, the project UI had not yet caught up to this dramatic shift in scope, leading to difficulties for users to identify which outputs have few drafts/comments, and differentiating between outputs.

Designs:

Prototypes 1, 2, & 3 of Outputs Redesign

Timeline: ~3 months for research, discovery, prototyping, design, development

Creating new products

In contrast, our approach to creating a new product or feature adheres to traditional Agile methodology principles.

When we first developed the Creative Intelligence platform, we had it in our heads that this thing would solve a problem or otherwise fill a need in the market based on everything we knew about our clients, their business, and the wider industry. Even still, let’s be honest, it was an educated guess. In this wild west world, any feature you build is going to fall into the “speculative” bucket, so the name of the game is speed.

Big things have small beginnings

This is where the MVP Mindset, #3 of our Product Principles — Big things have small beginnings — really shines.

Once we have an idea for a feature, (and more often than not these kinds of projects start with the words “wouldn’t it be cool if…”), we aim to ship it as quickly as possible to get it out into the world, and (ideally) validate that coolness.

We do this by taking precisely half a beat to think through the ideal state, and then work backwards to strip. everything. else. out. Everything, that is, except the absolute minimum for the thing to work and solve the problem it was intended to solve. No bells and whistles, just pure, unadulterated functionality. Polish can come later. Assuming the initial release is promising, it is only then that we start iteratively adding more functionality from the ideal state we outlined.

And it’s only once that ideal state is achieved, and this product or feature set becomes “old,” that we will come back around to take a magnifying glass to it.

Importantly though, if our “wouldn’t it be cool if…” turns out to be a dud, that’s ok. At VidMob we believe in failing…fast. Particularly when we’re working on a new product or feature set. After all, product development is a learning process, and the way we approach these types of projects vs. evolving existing products is specifically geared towards applying minimal initial effort and resources to be able to quickly pivot.

Creating a new product

Creative Intelligence: Watch Dashboard

“Wouldn’t it be cool if…” we could overlay performance data with a frame by frame analysis of all the visual elements in a video creative to understand viewer retention?

Designs: