Building a Winning Product Development Culture

This month marks one year since I joined the fantastic Flux team as Director of Product Management. Among the most rewarding work of the last 12 months has been playing a critical role in shaping the norms, techniques, and ways of working together that define the foundations of our team’s product development culture. As I reflect on the past year of growth for Flux and the future we’re preparing to scale for, there are several pillars of that culture that I believe are especially important: Our relentless focus on our users and the way we center them in our day-to-day; our iterative, “curious” approach to building that is anchored in hypothesis testing; and our approach to organization that balances structure and pragmatism. While you’ll hear lots more from me on these in blog posts to come, here I’ll share an overview on why I’m so excited about these elements of how we work.

Centering Users

Good product development requires a strong understanding of the needs and motivations of people who will purchase and use the product – this is not a new concept in the realm of software development. But how that understanding is best cultivated, iterated upon, and woven into the day-to-day work of a delivery team takes time to figure out and do well. At Flux, we strive to center our users in all that we do – not just in feature design, but in everything from the way we talk about and scope work to how we sequence and prioritize tech debt. Here are some of the ways we do it.

We’re on a first name basis with our user personas. When we talk about a new feature, we talk about how it will make Sarah’s (or Vik’s, or Bob’s) life better. We’ve dedicated a lot of effort (market research, discussions with folks who fit our ideal customer profile) to defining our hypothesized user personas, and we refine them all the time with new information as we talk to more prospective buyers, design partners, and users.

We revere user testing. We believe there’s no better way to build the right product than to get users into initial versions early and often. While our user personas are a great tool, and while many of us share experiences with them, it’s critical to remember that we are not our users. We find that the way to figure out how best to build a feature is to get people using a very early version designed to solicit their feedback, and then iteratively incorporate it to vector toward the right implementation. To this end, we’ve worked with cohorts of early users in our Alpha Program (last sprint and summer) and currently our Design Partner Program. From the folks we’ve partnered with in these programs, we’ve gathered invaluable qualitative data: Use cases and scenarios we had not thought of, feature tweaks and suggestions, and ways of articulating our value proposition to speak to these specific needs.

Thanks to working through the mechanics of onboarding and supporting our program participants, we’ve also been able to begin sketching out the contours of what supporting activities like account management and customer support need to look like at Flux.

Building Curiously

By “building curiously,” I refer to a mindset of developing and iterating on features based on qualitative and quantitative data from users. We strive to keep open minds and let the things our users find valuable be our guide.

We test hypotheses. Our team happens to include a lot of people trained in the sciences, and we bring our spirit of experimentation to Flux. For example: when we have an idea for a feature or some new functionality, we first test the hypothesis that it’s something users will find valuable. The way we do this is by scoping release slices that deliver the bare minimum of functionality that will get us the data we need to test the hypothesis. Once we find that the hypothesis has been supported, we’ll scope another release slice to deliver more functionality to test more hypotheses about how the feature should work. Rinse and repeat. By taking this approach, we spend our time iterating on features that our users most want, and we build them to work the way our users need them to.

We collect data. Above, I described the importance we place on talking to users early and often to gather critical qualitative data. But it’s equally important to gather quantitative data so that we can understand how users are engaging with features we are iterating on, as well as core product metrics like how frequently and for how long users are logging in. Collecting this data requires planning and forethought to ensure we are capturing the right events and meeting our high bar for customer data privacy and security. Therefore, our acceptance criteria for feature release slices often include details about the data we will need to collect in order to decide on next directions.

Staying Organized

I love working at early-stage startups. There’s something about being on the ground floor of something big – the scrappiness, passion, and focus of the teams who set out to bring a vision to life – that cannot be replicated.

When working with teams at this stage, it’s easy to subscribe to the notion that imposing structure, the dreaded specter of “process,” will create overhead that wastes more time than it’s worth. After all, we’re all on the same page! We know what to do next, we don’t have to write it down or have meetings about it. Until… you’ve started to scale your company, and now on top of demonstrating product market fit and hiring more folks to build out a stellar team, you’ve got to dig out of a few years of missing documentation and process too.

At Flux, we take a pragmatic approach to staying organized that we believe balances the minimized overhead we need to do creative work with just enough structure to ensure we’re on the path to scaling effectively.

We implement process “just in time.” At our size, we emphatically don’t need heavy process – and, anyway, implementing a process before it’s needed tends to result in the wrong solution, as well as a team that feels frustrated and overburdened. Our solution to this involves collaboratively identifying, developing, and iterating on processes only once there is a real need that arises. When we encounter a pain point (a sense of no longer knowing what other work streams are in progress; confusion about where to raise a suspected bug; lack of a forum to discuss details of product architecture), we decide as a team whether it’s time to tweak how we work together to do something about it. When we implement a new team process, we never want it to become “just the way things are.” Instead, we continuously work to cultivate a norm of taking nothing for granted and identifying areas of improvement in our process to make sure it’s working for us at our current stage, with our fortnightly team-wide retros providing a forum for these (often lively) discussions.

We write. Our writing culture at Flux has evolved as a function of several things: It’s how many of us naturally prefer to express ideas, we’ve found asynchronous sharing and digestion of ideas before meetings much more efficient, and having thoughts documented for future revisiting proves to be very valuable. When a meeting would be beneficial, we have one – but often, asynchronous communications work just as well, and are much more efficient. In order for asynchronous communications to remain efficient as our team grows, we try to be mindful about where they happen. For example, when discussing an issue, we comment in its corresponding Jira ticket instead of over Slack direct message. This keeps the conversation close to the context and accessible to everyone. We prioritize keeping documentation organized and current (and centralized in a single tool!) so that it’s discoverable and usable rather than obscured amidst outdated material. We use Confluence for documentation, and when anyone on the team creates a blog post in any of our shared Confluence spaces, we’ve got a Slack integration set up to notify us in a shared channel. This keeps ensuing discussions accessible to all (in the blog post), and gives the team the flexibility to review posts when it works for them.

As we forge ahead here at Flux, you’ll hear a lot more from my colleagues and I about our product development culture and how it evolves as we continue to learn and grow. Here’s to another year of building something remarkable with an incredible team!