A working prototype is sometimes the most exciting part of creating a technology product. Making that prototype into a product that real customers will use, pay for and depend on is a different story.
Even a very capable app can go wrong if it's solving the wrong problem, requires far too much customization, or simply doesn't integrate into a customer's existing workflow. For technical founders, the key to successful venture building involves orchestrating engineering with customer discovery and validation.
This is particularly relevant in fields like AI, IoT and industrial automation, where software frequently interacts with physical gear, legacy equipment and operational limits.
Here's a quick way to take a concept from infancy to something able to scale.
- Define the Problem Before Choosing the Technology
It can be seductive to lead with a technology-a machine-learning model, a sensor network, a new API, a real-time dashboard. But only after a problem has been explicitly identified.
A developer could suggest RFID tags, sensors, a database, and a dashboard for tracking.
Before building anything, investigate the current workflow.
- How are assets recorded and located today?
- How often are records inaccurate?
- Who needs location data?
- What existing systems store asset data?
- What would a meaningful improvement look like?
They help identify if the issue involves live-tracking, record management or search, or a combination of the three.
Before starting the first prototype, formulate a one-sentence problem statement. Briefly describe the user, the problem, how it affects the user, and the improved outcome of the proposed solution.
This prevents the team from coming up with solutions in search of a problem.
- Build the Smallest Useful MVP
This hypothesis can be evaluated by building a minimum viable product (MVP). A MVP can be used to validate an hypothesis in the least amount of nonessential complexity and is not a scaled-down version of the actual platform.
For the warehouse example, a first version of an MVP could enable workers to log items, read and change their locations, and query for the most recent location. A first version might roll out barcode-reading and a simple database instead of deploying all sensor types with an elaborate analytics pipeline.
This way the team can check whether improved asset information actually speeds up the work process.
A useful MVP should answer three questions:
- Can the product solve the core problem?
- Can potential end users use it in their real environment?
- Is the improvement valuable enough to justify further investment?
Limit the implementation in scale, but don't be too hasty to ignore the fundamentals: reliability, access control, data integrity, and privacy. Even a miniature prototype that deals with private operating data still needs its privacy.
Don't avoid engineering discipline. Don't build features until you see a pattern.
- Treat Integration as a Product Requirement
Nothing exists in a vacuum. Your business software might need to communicate with older databases, enterprise resource planning systems, identity providers, sensors, or third-party APIs.
A MVP might look successful when you demo it and have failed at rollout because the real-world environment introduces the boundaries that were absent when developing.
For connected or industrial products, consider:
- Data quality: Are incoming records accurate, complete, and consistent?
- Connectivity: What occurs when your device or network is offline?
- Integration: Can the product exchange data with existing systems?
- Security: Who has permission to view or edit operational data?
- Observability: Is the team aware of failures and can they diagnose what occurred?
- Recovery: How does the system respond after a service or device restarts?
You want to show an asset's latest confirmed location rather than an outdated record that simply has not changed because the device went offline. It can be extremely misleading to users to show out-of-date information as current.
And these details aren't just technical minutiae. They also influence whether customers feel that they can trust this product.
- Validate With Real Users, Not Just Internal Tests
Automated testing and code review can verify a certain degree of software quality but they do not confirm that a product fit into the customer's workflow.
Initial validation needs to be by the people who have the problem. Watch how they do it, identify where they get stuck and get them to write you workarounds.
Do not merely ask questions like "Do you like this feature". Look at behaviour.
- Is it possible to do the task unaided?
- Frequency of errors?
- Does the product minimize overly complex or unnecessary steps?
- What features do they actually use?
- Would they continue using it under normal working conditions?
Set success measures prior to the pilot. For asset-visibility MVPs, you might consider time-to-search, record accuracy, success rate of each task, the number of outdated or missing updates, etc.
Never assume the pilot will turn out well. If the product makes the process faster, great. If it does not, look at where it falls down - the interface, the data model, the environment where it is deployed, or the initial problem hypothesis.
If an incorrect assumption is identified early, it is typically more cost-effective than an assumption identified too late-after a significant deployment.
- Make Architecture Decisions That Support Learning
In the initial phases, early-stage teams might struggle to decide whether to design a highly flexible architecture or to keep the implementation simple.
Being too sophisticated too early can also hamper experimentation. Alternatively, shortcuts around data integrity, security, or system boundaries can be a costly pain in the long run.
A handy trick is to split out options which are trivial to change, and those which are much harder to take back.
A small app might start with a modular code base, a clear data model, tests, and an API boundary. It might not require microservices, a sophisticated event-streaming platform, or a large distributed infrastructure from day one.
When requirements are better defined, the team can add other elements as the real need begins to demand.
Before applying a new technology, ask:
- What problem does it address?
- Is that problem present today or merely anticipated?
- What operational tasks will the technology create?
- Can the team support it reliably?
- What could make that decision worth coming back to?
Good architecture doesn't prevent change down the road. It makes the unavoidable change manageable and doesn't introduce complexity that the product isn't ready for.
- Connect Technical Metrics to Business Outcomes
A product may be high test coverage, fast response times, and a clean code, but it's not enough value to keep the lights on.
While technical metrics are still valuable, teams should establish the link that ultimately results in customer value.
For example:
| Technical or product metric | Business question |
|---|---|
| API response time | Do users face irritating delays when trying to do things? |
| How fresh is the data | Can I rely on this display? |
| Error rate | The frequency of workflow failures |
| Problem time | Is less time required to perform the task? |
| User retention | Will there continue to be a benefit for the user? |
| Deployment effort | Is the solution installable for other customers profitably? |
These relationships help teams prioritize work.
https://apertureventurestudio .com/
Top comments (0)