Note: This post was first published in 2021.
Guiding Principles For Prioritizing Data-Driven Application Development
Outlining the parameters of your enterprise application and product lifecycle is essential to the success of any business venture. Every web or mobile application has a unique set of requirements, and therefore every product needs a unique set of guiding principles to help prioritize those requirements.
The following are a few examples of how PixelEdge clients and other leading brands have used their own guiding principles to develop a product roadmap and perform prioritization.
Venmo
Singular function
At launch, the popular payment solution Venmo had a singular benefit to the end user: it allowed friends to split bills quickly.
Thomson Reuters Middle-Market Funds
Multiple primary functions
Market research, events, and resources
Portfolio metrics, historical pricing, and news
Fund financials, dividends, and filings
Investee mark to market + more
inKind Space
Hierarchical approach
Primarily allows patients and their network to request and/or give support. Secondarily provides non-medical tips, local resources, and curated content.
Complexity of Function
Some enterprise applications require more complexity than others. Stakeholders should ask themselves: Is the product geared towards a singular function, or does it have several important functions? If it is intended to be multi-function, are all functions necessary at launch? Could functionality grow over time with phased releases to the added functions?
Enterprise Application Development Processes
Development processes involve different types of actions. Knowing what action types are appropriate for your team helps with communications and task breakdown. Each team comes up with its own list of action types.
One client chose the following processes while developing their initial prototype:
R&D: research and develop
Design: create a technical design without having to do any coding
Tracer: initial coding to make sure there are no technical roadblocks and confirm assumptions
Code & Deploy: perform programming, QA, and deployment
UX: build the user interface
To evaluate prioritization, some business stakeholders may simply want to understand the product’s main features and the corresponding level of effort. By contrast, an implementation team working on a weekly iteration cycle would have different actions such as research & development, technical design, and usability. Below is an example of action types used by an implementation team.
Devices and Channels
Understanding what devices and channels will be supported at what time can also be valuable to driving appropriate prioritization. Is the intent to create a product that users will access on a laptop, a tablet, on their phones, or via some other mechanism (e.g. a kiosk)? If the goal is a laptop or desktop, is the channel via a desktop application or a browser? If the product is intended to be mobile-friendly, is iOS or Android needed, or both?
Possible channels you may want to consider:
Web: Popular browsers running on various operating systems
Smartphones/Tablets: Android, Apple, and Microsoft
Desktop Application: Applications that run entirely on the device and not on the cloud
Smart Speakers: Devices that respond to natural language voice queries
Wearables: Smartwatches, fitness bands, etc.
IoT: Internet of Things
When thinking about your product roadmap, most companies decide to phase in all the devices and channels they want to support. Below is an example of how inKind Space mapped out theirs.
Frequency of Use & User Interface
Understanding the nexus between the different user roles and the frequency of expected use can be valuable for prioritizing product development. An enterprise application that is used by internal client staff on a regular basis will have different requirements versus an application that is used by consumers with a lower frequency.
The screenshot below shows a financial analysis product that is used by some end users for a few weeks every quarter — around the time new financial reporting data is made public. This usage pattern impacts the prioritization process, as it means that the enterprise application should be easy to use, with intuitive access to all features, data, news, and reports.
By contrast, the screenshot below shows the admin dashboard for the same financial analysis solution. Administrators use the dashboard on a daily basis. Hence, the admin dashboard has different needs and prioritization requirements. While the user interface has to be functional, it does not require as much design effort. A few users working on the product regularly will learn the product, so UX may be a lower priority compared to the example above.
Enterprise Application Development Pace
Understanding the pace at which you would like product development to proceed is a piece in the prioritization puzzle. Is it a sprint to finish V1.0 and then slow progress after V1.0? Or is V1.0 just the start, while subsequent versions will cover more features, channels, and devices?
Typical stages of application development:
Alpha: Initial release with basic functionality
Beta: Release used by a select end-users only
MVP: Minimum viable product with features useful to end-users but lacking other features important for wider adoption of the product
V1.0: Release for distribution to all appropriate end-users
V1.1: Subsequent release with tweaks and additional functionality
V2.0: An upgrade with major updates or changes
A study by Stanford University found that up to 90% of the overall cost can come after the launch of V1.0.
The diagram below shows the application development pace for Thomson Reuters' middle-market funds product.
Written by Ali Usman, CEO of PixelEdge.
Are there guiding principles you feel we have missed? Something unclear? We would love to hear your feedback.