About the author
As VP of Product at Fulcrum, Coleman leads strategy and development on all product development activities – from concept and engineering through marketing and growth.
Every day we find new customers using Fulcrum for wildly different applications for field data collection. Nothing is more exciting as an engineer than to see something you’ve built being used to solve real challenges, all over the world. However, as a fast-moving, agile software team faced with an enormous variety of use cases—sometimes with directly opposite requirements—you can’t build everything (nor should you).
Product development isn’t about deciding what you should build, that’s way too easy. Every software team with an evolving product has an essentially limitless backlog of “awesome wishlist” features and functionality that could be built.
All successful product teams recognize that evolving a high quality product with new features to grow business with customers is an exercise in deciding what you shouldn’t build, either now or ever. We’re all familiar with bloatware products that have been metastasizing for a decade (looking at you Photoshop). And large, featureful products like that aren’t necessarily a bad thing, but they definitely get “less good” at accomplishing what they originally focused on in the early years. That or they exchange ease-of-use for power. It depends on the desired customer and meeting their expectations more than anything.
Here are a few core tenets we try to hew to as a team to stay focused on building the right things:
Have a balanced approach to satisfying existing customers vs. building features for new customers.
With an existing base of customers, you’ll always have a long list of “nice to haves” that your product doesn’t do that would help them get more out of the system. It’s an absolute requirement for building a successful tool to pay close attention to what your existing users want—after all, they’re already getting value out of it (and paying you), so improving things for them should be a high priority. But on the other side you have the new prospects that aren’t yet customers bringing their own new requirements, too. We work hard to balance addressing both without leaning too far in one direction or the other.
Spend as much time as humanly possible understanding what your users do for a living.
This is about identifying where the value is in your toolset. Building complex business software involves getting to know your customer’s workflow to best understand why they use your software, and the touchpoints or places along the process where a new feature or software change would amp up their derived value. Often this requires understanding business rules you aren’t familiar with, but it’s the only way to get to the core of how they feel about your product.
See your product in action.
If you’ve ever read Don Norman, you know that nothing in software design and usability compares to seeing what you’ve built out there in the world. In the case of Fulcrum, the majority of the platform’s use is quite literally “out in the field”, not in a conference room or an office with tons of tools and alternatives on hand to fall back on when something doesn’t work. Going back to the point of “empathic design”, it’s eye-opening to see something you designed and built while sitting at a computer getting used out in the wilderness, wading through a river with a ruggedized smartphone. This is exactly when “unintended behavior” pops up, and you can’t appreciate the impact without seeing it first hand.
These are just a few of the lessons we’ve learned to keep at the top of the mind as we grow our software and platform. Having constraints makes for better results. And with constraints in developing products, you have to spend the brain cycles to strike the right balance.
Image credit: Andreas Levers