left arrow

How Hexa Builds Early-Stage Products

Victor Gross
Victor is a Product Lead at eFounders, Hexa’s future of work vertical. An ex-entrepreneur, his background includes leading the product team at Worklib and earlier, developing a platform to make government APIs public. In his role at Hexa, Victor's focus is on straightforward solutions and genuine improvements that make a real difference to users and businesses.

It’s impossible to pin down what a good product development process looks like. Depending on the type of product, the origin of the idea, your resources, and countless other factors, every journey to a great MVP can look vastly different. And if we did try to pinpoint it, it would turn into a thesis rather than a blog article.

To provide the most quick-win value, here are some actionable tips you might not have thought about that you can apply to your early-stage product development. 35+ products and companies later, they’re behaviors and mindsets that are not only clearly very effective but are so part of the way we approach product development at eFounders and Hexa that they’re now barely even conscious.

1. Your Users Might Ask For Faster Horses

People often don’t know what they need, and that includes your users. When building their first car, Ford famously said that if he’d asked people directly what they wanted, they would have said “faster horses”. Your job is to dig deep, and not take your users’ responses at face value. Consider a manufacturing accountant facing challenges in cost accounting. They might respond well to the idea of a tool that automates a lot of surface-level administrative tasks (who wouldn’t?) when in reality, their main issue is with gaining access to the decentralized financial data they need. Without taking the time to really understand this accountant, you could end up deciding to respond to a problem they don’t truly care about.

By nature, your best questions will be:

  • Open-ended, i.e. not prompting a ‘yes’ or ‘no’ answer. If you ask closed questions, your users will usually respond with a simple ‘yes’, even if the answer is actually no. Our minds are always on the lookout for shortcuts, and will usually favor an easy response if they have the option to give one.
  • Short: your best friend in the form of a question will simply be “why?” or “how?”
  • Prompting practical demonstrations when possible: there is often a discrepancy between what your users think they do, and what they actually do. Seeing them in action will help you get to the bottom of their behavior.

Doing this will prompt meaningful insights that will lead you in the direction of creating a great product.

2.  Keep Your Biases In Check

Everyone knows bias leads to bad products. But the point deserves repetition because it’s human nature to seek out confirmation for the things we want to be true and to ignore any hint that goes against it, which is a death sentence for your product before it sees the light of day. Even at eFounders, it’s a lesson we have to learn over and over again during the discovery phase and requires a lot of self-awareness and humbling moments. You need to learn everything—absolutely everything—there is to know about your users: the ins and outs of the way they function, the things that work well, and most importantly, the things that don’t. And of course, you need to allow them to genuinely shape your discovery. Only once you’ve done this can you even think about starting to write a hypothesis. It goes without saying that this open-minded, genuinely curious approach is the only way to build a product that people genuinely need.

Before pursuing your hypothesis, here are a few things you can do (other than the obvious customer interviews, competitor analyses, etc.) to make sure it’s well-informed, rather than the product of an unchecked mind. You can ask yourself:

  • "If I’m really honest, am I more attached to my idea than finding a solution to my users’ needs?"
  • "If there was a breakthrough insight tomorrow that revealed my hypothesis was probably wrong, would I continue pursuing my idea?"
  • "If this idea came from a hypothetical person I didn’t like, would I think it was a bad idea?"

If your answer is ‘yes’ to any of these questions, it could be a sign you need to head back to the drawing board.

3. Work With Design Partners ASAP

As you move from discovery into the validation stage, you need to continue working with acute intention and awareness, making sure that every mock-up gets you closer to validating (or challenging) your hypothesis.

A great way to do this is to work with design partners: people who would greatly benefit from your product, and review your prototypes as you create them. You get to make sure your product is on the right track, while your design partners gain early access and preferential prices to a product that will one day make their lives a whole lot easier.

At eFounders, our founders solicit the help of design partners from as early as a few weeks into their time with us. While we have an expansive network they can tap into, you can also leverage LinkedIn to find people who might be a good fit. Look people up in the industry you’re targeting with the job titles you want and reach out to them directly. To add credibility, you can also post about your project on your personal account, describing the product, mission, and the advantages of being a design partner. This way, when the person you’ve contacted looks at your profile, your project will carry extra weight.

4. Prioritize Adaptable Milestones Over Fixed Roadmaps

Detailed product roadmaps are appealing as they convey a sense of purpose, vision, and clarity.  They're valuable assets for mature products that thrive on fine-tuning and feature enhancements, but they won’t serve you in the early stages of product development.

The initial stages of your product's journey demand agility. They require the freedom to switch directions as you discover more about your user's needs and as you receive crucial feedback. Locking yourself into a rigid roadmap can mean missing out on these vital learnings and potentially derailing your product from its most valuable path.

Instead of painstakingly plotting out every minor step, consider:

  • Setting broad milestones: Sketch out where you want to be in six months. What's the bigger picture? What are the milestones you want to achieve?
  • Not planning beyond the next two weeks: Reassess the main actions to be completed very frequently to make sure you remain flexible and responsive to feedback.

To make sure you’re not overcomplicating things, set them out in a simple list or table — don’t involve complex project management tools. Here’s a classic example of a milestone document  you might find within a project at eFounders:

  • February: Secure at least 5 design partners
  • March: Test prototypes with all design partners
  • May: Deliver MVP

The key is to create a framework that is as simple as possible. This not only brings clarity to the team but also ensures that everyone is zeroed in on achieving the initial wins through tangible, short-term milestones. Overcomplicated roadmaps that undergo constant revisions are not only time-consuming but often fail to reflect the true trajectory of the project.

Kiosk’s map of early milestones

5. Sketch Your Early Prototypes

At the very beginning of the prototyping phase, don’t design your screens and features beyond keywords in boxes. The idea is to trigger conversations with your design partners before jumping into more sophisticated designs, to make sure you are on the right path every step of the way. If you can, stick to sketching, whether on whiteboards or paper. This isn't about nostalgia; it's about flexibility. Keeping your designs a bit unattractive at this stage ensures agility and lack of attachment, allowing for quick iterations. Focus on functionality first, and only once that's solidified should you refine the visuals. Remember, clarity is paramount in this phase, and intricate design can sometimes cloud that.

Here's a good example of how basic an early prototype can be:

Aircall’s early product prototype

6. Create Your MVP Around Its 'Dry Elements'

You’ll know it’s time to start building your MVP once you have a few dry elements, or features with no risk that absolutely won’t change, based on your iterative prototyping with your design partners. Once you have them, you can start coding.

Your MVP shouldn’t be more than 3-4 simple screens, and by its very nature, is the distilled essence of your product, so don’t add any features that aren’t absolutely necessary. You can add those later if they still seem like a good idea.

It's actually better to launch a product with clear, easily understood features, even if they aren't at full power yet. If users are asking for improvements, that’s a good sign: it means they’re using it. On the flip side, it’s a sure signal that something’s gone wrong if you have spent a long time developing a complex feature that remains untouched. This approach sets the stage for better onboarding, helping you introduce and refine features in a way that users can easily grasp.

7. Carefully Consider Your Architecture

A product’s front end is key, but the importance of its technical foundation shouldn’t be underestimated. Think of your database as the unseen engine driving the user experience. It powers seamless interactions, making every feature feel intuitively connected to the user's needs.

The architecture will set up your product for the rest of its life, so it’s necessary to stress-test it. Think about some scenarios that could pan out in the future for your product and check that your database can support these changes. Make sure you’ve also factored in your desired UX, as your architecture can affect this as well. For example, if you want to give users flexibility in terms of how they can view data, like letting your accountant user see costs from both an inter- and intra-departmental perspective, your database must be structured accordingly.

A great way to make sure this is accounted for is to have your architecture challenged by 3-4 tech leaders around you, and to bring a CTO on as a co-founder as soon as possible. This is what we do for all of our projects at eFounders, and is the best way to make sure that all aspects of your products work for each other, and not against them.

Every great structure begins with a strong foundation. The same goes for products. The initial phases of product development aren’t just stepping stones; they are the very heart of what your product will become. The choices you make, the feedback you receive, and the changes you integrate will echo throughout the product's life. As creators, it's easy to be dazzled by innovation and quick wins, but the underpinning fundamentals are what set the stage for lasting success. At Hexa, we've seen firsthand the power of a well-laid foundation: Our projects typically find their first customers within 3-4 months, a milestone that can often elude companies for much longer than that.

If you're inspired and interested in how eFounders could help you execute your idea, we'd love to talk to you about it.