Workplan For Launching New Products
Agile versus waterfall development is usually a matter of resolution. For some projects, the right length of a single iteration is a month, including everything from design, to development, and finally to testing over paid traffic. Other projects require a longer breath of air. This could be because a technological challenge is at the basis of the product’s definition, and it could be because the business goal only makes sense when launched at a very large scale.
This post describes the process we, at Initech, as a web development company, offer clients prior to starting development on the latter type of product. It details a process that has a waterfall-like structure when written down, but is in fact a maze of dependencies among tasks, and of feedback sessions that produce unpredicted extra work. However, as a framework for starting out, and as a basis for discussion on the grounds of a common language, it’s a useful tool to have at your side.
We start the process with a meeting that includes all the personnel from both sides, and continue into three stages of planning – product, design and technology. Some aspects of the work are better done by us, and others can just as well be accomplished internally by the client. The rest of this post lays out the details of these stages.
We start the project with a meeting in which we’ll decide on the terms of the engagement. This includes aligning the expectations of both sides with regard to forms of communication, time investment and frequency of interaction. This is also an opportunity to introduce key members of both teams and create direct lines of communication.
Product definition
Ideation
The product definition stage starts with a brain dump process in which we’ll list all possible major features, future prospects and sources of inspiration. This stage is both a desk job, done internally at Initech, as well as a subject for a meeting with the client’s team. The point of the process is to open a horizon to various possible directions before we decide on the single path that best fits the chosen target audience and business goals.
Market research
As part of the internal process at Initech, we map out a list of possible user personas, from a product rather than a business perspective. However, we suggest that the actual market research work would remain within the client’s team, as it relates closely to marketing and business efforts. This involves defining prospective sub-groups of clients, as well as interested third parties. During the market research phase, both sides should make an effort to reduce the product definition to a single major pain that’s in need of solving.
Related products functional survey
A survey of the competitive environment is meant to complement our understanding of the possible business models, features, and target audiences of a platform similar to our own. We do not assess the business or financial prospects of the project, unless specifically asked to by the client. The analysis of competing products is only meant to enhance our understanding of the requirements and possible feature sets of the client’s platform.
Actors
A major component of the product definition stage is the actors description. This is an internal process done within Initech, meant at listing the different types of users of the system. Actors include anyone that has a role in the system, including backend administrators, third parties with which we cooperate, and entities that don’t use the system but are affected by its existence. A relevant example would be distributors whose products would be sold within the client’s platform, and that might and might not have access and control over the inventory management and content authoring that relates to the selling process.
Features mapping
The next step of the product definition stage is to define the full list of features out of which the full blown product would be comprised of. This includes everything we think would be beneficial both in terms of user experience and engagement, as well as in terms of achieving our business goals. This stage involves both desk work on Initech’s side, and a meeting to discuss and finalize the results of the analysis.
Roadmap definition
Based on the mapping of the entire feature set of the platform, we conduct a meeting meant to reach a clear definition of the project’s roadmap, in terms of major features. The first stage of development should be concluded with a working product that’s ready for public release, but that’s lacking some of the features that are less user-facing and aimed more at achieving our business goals. The following stages of the roadmap would provide a framework for future work, taking into account the fact that business and marketing related goals would change according to user adoption and feedback.
User stories breakdown
Given a product definition and a list of features for the first stage of development, we create a breakdown of the features into units of functionality called user stories, each signifying a major action that a potential user can conduct within the system (such as logging in, reviewing his profile, or buying a product). We group the user stories into epics, which are large modules of functionality. This creates a basis for work and a common language during the design and development stages.
Design
User workflows
Planning a product’s design starts by mapping out all the routes that a user might take when navigating through the pages of the application. We sketch all the different paths into a chart called the user workflows chart. This is sketched out in the level of user stories and does not reflect every possible edge case that the code will need to cover. Instead, the purpose of the user workflows chart is to provide the framework over which to discuss the structure of the user interface and the planning of the users’ experience.
Information architecture
User experience planning involves the analysis of what user actions are required in order to reach the user’s goals within the application, and the types of information that should be available to the user while navigating through the application.
Key wireframes
We’ll work together with the client’s team on a set of wireframes for the major views of the application. This stage is a mutual process, during which we discuss the significance of competing call-to-action triggers, and equate ease of use with flexibility and options. The result of the process should be a set of low resolution wireframes that would form the basis for the prototyping work later on.
Interaction design
We create a document that describes how the application reacts to user actions. This includes a description of the mechanisms used to indicate to the user that she needs to perform an action, or that something went wrong or that a user input was mistaken. This document forms a basis for development later on, but is only a basis, and is assumed to change during the visual design process.
Prototyping
Before going into the full blown process of design and development, it’s necessary to validate with user testing that the application accomplishes its stated goal. This is done by performing user testing over an interactive prototype of the application, prior to visual design. This stage also prevents a major portion of the back and forth involved with the design and development stages, because a large portion of the fine details have been settled over the prototype version of the application.
Visual design
We suggest separating the design and branding work from the bulk of the planning stage, taking into account our conclusion from past projects that visual design has more to do with a match in taste than with the technical experience required for other aspects of planning. A visual design process includes defining user personas with their common characteristics, deciding on a brand identity that best serves those typical personas, creating a brand guidelines document, defining the unified design of common web/mobile application components, and designing the application itself as a whole. The process is comprised of an initial meeting meant to understand the client’s visual preferences, and multiple iterations until a common language is reached and a full design can be presented.
Technical specification
Functional specification
A functional specification will be written based on the prior breakdown of the first stage of development into user stories. Each user story will include its ‘conditions of satisfaction’, and would relate to an application view and to a component of the data model, where applicable. The specification document would also shortly describe the system, its goal and its major features.
This document describes the hardware and software requirements of the application, as well as the architecture of the software components that comprise it. The document lists the development stack and the ready-made components that will be integrated into the system. The technical approach document also lists a suggestion for the data model, meant only as a suggestion, so that it would assist the development effort instead of restricting the developer. The document would later list the major risks and technological challenges we can predict based on past experience, and decisions as to how to diminish these risks as much as possible. Finally, the document would list the plan for deployment during the beta and release stages, taking into account concerns such as scalability, response times, and durability.
You are welcome to visit our website www.initech.co.il or write us an email contact@initech.co.il
The article was written by Initech Team
