Building the right product, the right way

Spencer’s product management approach

As the team behind Spencer, we believe a great product should be the first concern of every startup — which is why we’re working hard to involve our clients and their employees as well as the rock-stars building our product, at every step of the way.

With Spencer, we set out to build a product to make large companies’ workforces more engaged and more efficient, by creating a unified interface for all of their business-critical tools. In this article, we’d like to go into some more details on our product management approach — which is the backbone that supports our product!

Our process consists of a number of steps. They can roughly be broken down into two main blocks which go hand in hand:

• Building the right product: making sure you understand the customer need, solve it and provide maximum value to the end user as quickly as possible. This part of the process is mostly external, focusing on the dialogue with our clients and their employees.
• Building the product the right way: making sure our developers are involved from the start, hear the customer input, understand why we’re building things and can perfect how they’ll build it. This part of the process is mostly internal.

At every step in the process, we ruthlessly evaluate and prioritize. Is our focus right? Are we focussed on maximising the value for our customer? Will this module or feature have the impact we’re aiming for?

Building the right product

The key to success is to understand the problem, stare it right in the eye and then build the solution. And as we do that, we always prototype our solution and put it to the test. We put it in the hands of as many employees and client stakeholders as we can, to learn about the things that matter most.

Does it solve the problem? And not only that: does it solve the problem more conveniently, quicker or in any way better than the previous solution?

Apart from constantly tweaking the product, at Spencer we’re often building new functional modules that can be enabled and configured to fit specific client needs. We try to get as many perspectives on these modules as we can, to fully understand what employees are looking for and find out what they like and dislike about the prototype. We do this early, in the prototyping phase, so that we can tweak and run another feedback loop when needed — before writing any code.

As we decide on the functionalities for a module, we already start defining how we’ll measure whether this module is meeting its goal. Defining this early in the process — again, before we start building — ensure that these analytics are an integral part of the module, and not an afterthought.

Fast forward through our development cycle!

Once that module is ready to spread its wings, we evaluate again whether we’re meeting the goals we set. We user-test the functioning product with additional client stakeholders and future end users (employees of our clients). This leads to the final tweaks in the existing version, and a bunch of improvements for the next iterations.

Based on the feedback, we also define how we should communicate about the module. We want to broadcast its existence throughout our client company in a way that really resonates with the employees — so we do it in the words of our test group!

Once the module has been shipped and communicated, we carefully monitor the adoption and user behavior.

Our process of putting user-testing in a prominent position convinces us that we’re building the right things for our customers. We’ll then verify how we can further improve and maximise the impact — more on the impact drivers, user-testing pre-launch and product analysis post-launch below.

Building things the right way

In parallel to defining what we’re going to build, it’s equally important to then build things the right way.

To achieve that, we try to keep our entire team involved from start to finish. Our prototypes are shared and reviewed not just with end-users, but also with our developers. This way, they understand what we’re trying to achieve and the value we’re trying to create, and they can share their feedback and ideas — both functional and technical.

By the time the feature is defined and documented, our developers know it inside out, they’ve contributed to it and made it their own. Most importantly, they know why we’re building things in that specific way.

It also sparks their thinking on how the solution should be architected, what extension might be interesting, which tracks have which limitations. Overall, we found that we end up with a more modular, more extendable and more maintainable product.

Sure, deep involvement takes a bit more of our time — we work hard to limit this to between 30 minutes and one hour per week — but it pays off. We find it results in greater understanding of the “why”, better ideas on the “how” and a deep motivation to get value out to our customers as soon as possible, and then measure it and improve where possible.

To get product value out to our users as soon as possible, we’ve got a set series of ceremonies that we run through, in preparation of a sprint and during a sprint. These processes make sure we can ship valuable product at the end of each two-week sprint.

Guiding principles to maximise the value of our product for the user

At every step of the way, we consider what we’re trying to accomplish: to maximise the value for the end user in our next delivery.

This is why we prioritize features ruthlessly: across modules, which features / tweaks / improvements should we build now (and more importantly, which ones shouldn’t we), to deliver the greatest value to our customers and our shareholders?

Software only provides business value when it gets shipped; unreleased software has no value whatsoever.

Software also only provides business value when it gets used; unused software has no value whatsoever. And a feature is only used when people know about it, making communication a crucial aspect of a successful product.

Interesting fact: when Microsoft asked their users what features should be added to Office, they realised 90% of the requested features were already there. People just didn’t know they existed or where to find them.

And finally, it’s imperative to keep continuously evaluating your product and its features. Is it delivering on its promise? Is it having the impact you intended it to have? The answers to these questions can then close the loop, and again inform the prioritization of new features and changes.

And that’s it! This is how we handle our product behind the screens.