In my experience of working with diverse products across different industries, I have noticed that product engineering teams may overlook non-functional requirements when the user stories are not comprehensive enough.
In this article, I will share some of my key learnings, improvements, and examples in the product development process.
Note: The improvements may sound simple. They can be tricky or complex in some products and need to be handled based on the use cases.
- Network Interruption/Slow Network
Network interruptions or slow networks can prevent users from completing desired actions, with the validation being done on the submit action. Users may only realize that there was a network disruption when they try to complete the action.
Improvement: Set a minimum desired speed for the product, detect network fluctuations, and inform users of the network anomaly.
- Large Media Files Upload
Some product features require large media file uploads, which can pose challenges such as displaying the upload progress and resuming the upload from where it was interrupted.
Improvement: Use services such as AWS TransferManager for multi-part uploads, or implement a “pull approach” similar to Vimeo. Depending on the use case, you may also need a distributed file system for storage.
- Third-party Service Fallback
Third-party integrations such as payment gateways, text messages, and phone verification are common in products. Most third-party platforms may have close to 99.99% reliability. However, there may be outages in the service for multiple reasons.
Improvement: Have a fallback mechanism with a similar third-party service to avoid disruptions.
Example: Integrate Stripe & PayPal payment gateways.
- Error Messages
Vague error messages such as “Something went wrong” do not help users understand the cause of the error or what action to take for error correction.
Improvement: Write error messages for “humans” that are easy to understand and provide guidance on how to rectify the issue.
Example: “Your account is currently disabled because your most recent payment failed. You can update your billing information here.” (“here” is a link to the payment page) message makes more sense than “Your account is currently disabled. Please contact support.”
- Data Syncing
When a product supports online/offline syncing, it can be a challenge to maintain versioning and sync data across devices accurately.
Improvement: Clearly define rules for data synchronization, especially for conflicting data. Depending on the use case, you may handle sync based on the order of actions, failure error, and conflict detection with the option to select revision or last write wins logic.
Example: Evernote
- MVP Feature Size
The mistake of assuming that an MVP should be the smallest possible version of the product with just enough features to launch or adding too many features to the MVP can lead to long development times, high costs, and increased complexity. Another mistake is to add too many features to the MVP, which can lead to long development times, high costs, and increased complexity.
Improvement: Identify user needs and offer sufficient value to early adopters. Prioritize the most critical features that provide maximum value with a reasonable development effort.
Example: Google Wave in 2009 had over 40 features, making it challenging to understand and leading to poor user adoption.
- Technical Debt
Technical debt is a natural part of software development. The most common mistake is acknowledging that a product has a technical debt. Ignoring the long-term consequences of technical debt and focusing only on short-term gains lead to increased costs, reduced innovation, and decreased competitiveness as compromises are made in quality, maintainability, and scalability.
Improvement: Maintain and monitor technical debt backlog, prioritize, and make small changes over time instead of doing everything together.
Example: The codebase of Netscape Navigator in the 1990s was developed rapidly, leading to difficulty maintaining and developing new features and declining popularity.
- Product Health Status
In the early days, the product teams had a challenge in knowing the health status of various services. When something went down, the issue was reported by the client or an end user. That led to scrambling the team, identifying the issue, and then resolving it. There was substantial downtime at times. This is more of a reactive mechanism.
Improvement: Monitor the health of the infrastructure using monitoring services, and setting warning & failure notifications to the support team. Also, track the health status of various services to immediately identify the issue & resolve it. Move away from the reactive to the Proactive mechanism.
Example: Stripe system status, Twilio Status
I will continue to maintain this article as a master list.
Feel free to share your learnings and suggestions. I will include them in the master list with attribution.