Creating a Product Development Lifecycle for Small Teams

Houston, we have a problem.

Software Development has a naming problem. Well, ok, maybe it has several naming problems. If you are a Software Developer, Product Manager, Project Manager, or Engineering Supervisor you’ve likely heard some of these terms in the workplace that describe your development process:

• Agile
• Incremental
• Iterative
• Waterfall
• Minimum Viable Product

I apologize in advance if any of these terms bring about PTSD from a former job…

Folks have tried in many ways to ceremonialize bridging the gap between Product Owners, Designers, Developers, and Sales in a way that can accelerate development while keeping communication lines open. Of course, all of this is done with the best of intentions, but it has been said “the road to hell is paved with good intentions”. Project Managers get over-enthusiastic about project coordination and schedule an all-hands meeting any time someone has a question. Communication is often not documented as requirements. Product Owners will often short-circuit the development lifecycle to suggest changes. User Testing is left out because of the overhead in time and cost. For smaller teams and startups, these issues are magnified by the fact that one person may take on multiple roles for the company.

Product Development for Small Teams

Now that I’ve talked about some of the problems traditionally encountered in communication when developing software products, I’d also like to talk about some of the ways we’re looking to solve them at Clearview Social.

all good client projects start with a person in a suit saying, "our devs will have this done in no time, don't you worry".

— I Am Devloper (@iamdevloper) May 3, 2018

How we start: Vision

We start by getting together to discuss ideas we either have for our software, or features that users have requested of our software. We discuss the level of difficulty we may encounter developing the feature, and how the feature will positively (or negatively) impact our users. Obviously the double-win here is finding features that are high positive impact with low-difficulty.

How we create: User Stories & Feature List

Many organizations will distill new products into lists of Functional Requirements and Non-functional Requirements. Both are used to highlight aspects of complexity that may not have been fully developed in initial discussions. This can be a lengthy process though, so what we do instead is to develop User Stories, which might consist of statements like the following:

• A user should be able to submit their own posts for approval
• An admin should be able to reject a post

This gets broken down further into a Feature List that a developer writes, taking the User Stories and turning them into specific functions within the interface. Using our previous example, that might be something like:

• A user should be presented with a “Submit” button for submitting their posts
• An admin should be presented with “Approve” or “Reject” buttons
• Users will receive an email when a post is rejected

These lists get circulated with all involved parties (Product, Client Success, Developers, and Designers). By creating these lists, we are now better informed of time that will be required in creating the product we may not have previously discussed. For instance, we now know we will need specific messaging created, an email template, designs for buttons, and more.

How we design: UI Screenshots / Prototypes

Once we’re relatively satisfied with the Feature List, our UI / UX Department will build the initial designs. They can ask questions about the features requested, and are in a good spot to notice anything else missing. These initial designs provide feedback in a Design Spec, which is also reviewed by Product, Client Success, and the Developers. The spec helps provide the following:

• Visual cohesion between new and existing designs
• Basic text/verbiage for the product or feature where required
• A basis for developers to start creating the new product or feature

How we develop: Iterations & Feedback

Once we have an approved Feature List and Design Spec, we are able to develop with focus on our project. We work to break down development into phases:

• Back-end or API changes that don’t alter the UI
• UI changes per unique aspect of each feature
• Complete UI changes for the product or feature

There will often be dependencies between these layers, and sometimes it is impossible to roll out a feature in an iterative manner. However, we strive to plan in a way that makes this the exception rather than the norm. While developing, we often provide screenshots of what a “real implementation” looks like, as oftentimes initial designs are idealistic in terms of things like text length, image aspect ratio, and so on. If at any point we notice missing features or functionality, we add them to the Feature List and circulate those updates. If necessary, the Design Spec will receive updates with the missing functionality, and the spec is re-circulated and updated for development.

When visualizing this process, you can see the Developer acts as a sort of communication hub, for enumerating features and facilitating discussion with all parties.

In Conclusion…

At Clearview Social, we have taken an approach that is a sort of hybrid of Agile and Incremental methodologies. I don’t believe there is a one-size-fits-all approach to software development. Teams should customize their product development plan to the personalities, timeline, and cost that they incur. One thing is important to understand right away though: You cannot afford to develop without a product development plan.

Thousands of new products go on sale every year, and manufacturers invest a lot of time, effort and money in trying to make sure that any new products they launch will be a success. Creating a profitable product isn’t just about getting each of the stages of new product development right, it’s also about managing the product once it’s been launched and then throughout its lifetime.

https://productlifecyclestages.com/new-product-development-stages/

In a future post, I’ll dig deeper into automated testing, user testing, deployment, and some of the ways we strive to refine our products after deployment!

Until the next time,

Happy Sharing & Blogging!

 

Eric is a Senior Full-Stack Engineer for ClearView Social. He has worked in the web development world for more than 15 years. He’s done time as an author and speaker, and is the organizer of the JavaScript Meetup Group, BuffaloJS.

Click here to download our strategy guide: 10 Ways To Get Your Employees Sharing To Social Media – https://clearviewsocial.com/info/10-ways-to-get-your-employees-sharing-to-social-media/