5 Ingredients for Digital Product Development Success
In my career I have worked with and interviewed hundreds of permanent and prospective employees with various professional capacities: creative, technical, managerial. What I am always surprised by is the difference between the total number of projects that they have worked on, which they go to great lengths to detail in their resumes and LinkedIn profiles, versus the number of successful, lasting, google-able projects they have been a part of. This has been particularly relevant to me lately as I have been recruiting mobile developers specializing in a popular hybrid framework and any experience they can point to at a successful startup or tech giant greatly increases their chances of landing an interview.
There is certainly something to be said here about success breeding success as well as a novel to be written about how much creative and technical effort is exerted on failed projects in the pursuit of the next great idea. I’ll even note that in one recent case we chose a young-gun millennial who had worked on an Apartments.com mobile app rebuild over a seasoned hybrid framework veteran who simply lacked affiliation with any major brand.
But herein lies the fallacy. The resources companies use to accomplish tasks, ranging from creative to technical, are generally not responsible for a projects success or failure. I would argue that, and especially with App companies, a projects success or failure is in the hands of senior leadership and most importantly the product manager.
The Secret Sauce
During the time I have spent in a PM position I have lead the development of both kinds of projects: some successful and others unsuccessful. As a result, combined with ceaseless analytical introspection, I have come up with what I believe is the sauce for ensuring product success. We will use a list format for easy digestion. Here we go.
1. Dealing with Ideation
Learning to collaborate effectively is key for any profession and has significant advantages during the creative process and brainstorming. When everyone on a team also share the same foundations for the end result of a product, ideation sessions can make developing concepts effortless and exciting. Whiteboards are filling up with great ideas; your team mates are thinking of scenarios and possibilities you would never have considered. This is the ideal scenario.
The issue, however, that stems from this is that the creative capacity of human beings is so infinite, the reward for formulating a good idea so gratifying, that ideation, if left unchecked, will go on endlessly. Every member of your team, every person you meet on the street, your CEO, everyone will continue to bombard the product development process with perceived innovations and value adds until it is impossible to nail down a product concept. ‘Scope creep’ on steroids.
This app would be better with a… We should use this trending style of… We should gamify these… I saw another app that had…
Are these ideas bad ideas? That can only be determined with respect to your business objectives. Are they good ideas? Well, again, that is determined by business objectives as well as the scope of the project. The challenge here is to not eliminate new ideas or input, but rather harness it to be the most productive. Here’s how:
When developing new concepts or working on a new module, release or version, ensure your team understands that THIS is the appropriate time to indulge in deep ideation. Ideas at this stage inform the articulation of user stories and the sacred texts that will guide the rest of development. Create clear boundaries to distinguish these times.
Make it clear when intense ideation is counter productive through a mechanism. Here’s a great way. Create a safe space, whether an email inbox or collaborative wiki in your project toolkit, where your team can express ideas. It is paramount that this space be easily accessible by all. Not only does this allow the flow of ideas to continue in a non-disruptive and quiet manner, but it creates an organic repository of ideas for you as the product manager. Less thinking to do later.
Ready for the bonus? Through this you will also learn who your idea rock-stars are because they will embrace the mechanism for channeling their creative input. Alright, moving on.
2. Compiling the Sacred Texts
Developing a product without the following documents is effectively sacrilege: user personas, user stories, task models and product requirements.
User personas are a collection of behaviors that your intended audience are hypothesized to exhibit. These are an incredibly handy reference when considering a new feature or product changes impact. Organize these in a few power point slides and drop them in the appendix of every presentation for quick reference. That way new suggestions can be filtered through articulated user personas and product direction can be validated.
User stories are the meat of what your product is built around. These are loosely constructed anecdotes detailing the expected user experience. User stories are the building blocks for design and technical requirements and will be referenced until the completion of the project. Perhaps even beyond. You should be as thorough as possible and remember that, yes, as Product Manager you are responsible for thinking of every possible use case immaginable and documenting it in order to ensure there are no gaps when the product is completed. This is the time to begin that exercise. We can use a word processor for some examples:
User creates a new document or opens an existing file saved locally or online… User utilizes traditional text input or voice recording device to draft their text document…Tools for formatting the text are contained in a ribbon above the text input area and opened in modals when selected…
Task models are a natural progression after the development of your initial user stories. The difference is that a task model is a detailed description of the process in which a task is accomplished. Starting on a precise screen, if it’s a digital product, indicating which buttons or functions are engaged with and then detailing the indented result that follows. So when your developer is asking about where exactly a user adjusts a particular setting, the task model stands in the gap.
Requirements are as simple as they sound. These are the exact development requirements necessary for design and development resources to complete their respective tasks. Often these are organized in backlogs and boards in project management platforms, but that doesn’t mean the same can be accomplished with a simple word processor or even a cork board covered in sticky notes. Even if your project is being run using an Agile style methodology, a thorough and well developed set of project requirements will allow you to call back to your original product concepts without losing some of your product structure to time or the influence of rogue ideas.
You will reference these documents from the start of the product development life cycle to the end. And when circumstances force you to replace an employee in the middle of a project, these docs will save you countless hours communicating as much developmental and conceptual context as possible to ensure a seamless transition.
3. Affording UX Development
This one’s simple. Make sure someone on your team has professional experience in testing, evaluating, and designing user experiences(UX.) No, this is not just a component of good design or an attribute that good developers have. Though, you may find a designer or developer who have these skills as well, making them more valuable. User experience is an art and a science. It takes into consideration the psychological impact of unfamiliar page elements or laborious tasks while still concerning itself with modern aesthetics and digital sensibilities.
This also allows you the opportunity to develop prototypes without investing heavily in creative mock-ups. Team members are able to experience the app and its varying functionalities without the delay and contention that design can add. I would recommend a company called Marvel, which has a number of valuable prototyping tools that can be used to easily share concepts and ideas. I’ve often heard this said of prototypes: if a picture is worth 1000 words, a prototype is worth 1000 meetings.
4. Addressing Feedback (or not)
A lesson I am glad I learned early was that new ideas, suggestions and feedback lack context and value without understanding the foundations of a project. Here is an exaggeration for illustration purposes:
Let’s say you built an e-learning application that’s primary function was to demonstrate and teach basic construction techniques. Let’s also assume you’ve used video as your medium and your user personas identify your target audience as international and primarily males between the ages of 35–55. You share your project with a coworker and their reaction is,
The layout is all wrong. There is not nearly enough pink and these videos are far less effective than a blog article…
Using your judgement may cause you to arrive at the conclusion that this is preposterous, but it may not in all cases. Here is the key. The user personas and other business objectives or requirements provide all the necessary context. The demographic is older males and we are also targeting an international audience in this scenario, which would support video as the superior medium for the transfer of information.
I am always surprised by the concerned looks I get from social media managers and community managers who are shaken by community feedback that, when filtered through defined project variables, are really inconsequential. If the feedback is valuable, however, with respect to stories, personas and requirements, then it belongs in the safe space for product input we discussed when dealing with ideation.
5. Hunting Down your Metrics
And finally, metrics. Success, and in our case product success, can be broken down into metrics. As an example, let’s define success as being rich or wealthy. Well then what are our metrics. Possibly the number of dollars one owns, the value of their assets, the rate at which they are acquiring capital. We certainly wouldn't define success, in this example, in terms of the number of positive social relationships or how much money they spent.
Now think about your analytics dashboards. Line and bar graphs displaying usage and engagement. Wheels of color delineating demographics and identifying trends. An infinite number of widgets, filters, sorts and screens. Completely useless if the content you are reviewing is divorced from the key metrics that indicate your progress toward your goals or if you are on the path toward your definition of product success.
As product managers we are responsible for becoming the reflexologists of our key metrics, poking and prodding our published products until we find what causes improvement. Where do we invest our time, design, development in order to cause our key metrics to improve and take us further toward our definition of success.
Define these. Understand the direct link between your users behavior and the most valuable metrics for your company or business. Experiment with changes and learn. Ignore the fluff and endless segmentation of the traditional analytics dashboard and focus in on what matters.
With every project our experience grows and, in turn, we grow as product managers. Embracing these points will add some structural spice to your product development and hopefully increase the chances at facilitating lasting success.