How to think of software projects as Product Development Initiatives

Many suggest that building software applications should be approached with a product development mindset. Great! But what does that mean? This paper covers the ideas of Product Development applied to software development and highlights some important differences. If you don’t know the difference between Product Manager and Project Manager, you are in the right place. Or if you’re curious about where good product ideas come from, keep reading. There are values in adopting the product development mindset for software applications, and perhaps after you finish reading this, you too would want to adopt the Software Product Development mindset.

Preamble

When Netflix started their streaming service for movies, the quality wasn’t great; the resolution was so low that you could see pixelated images, the initial buffering would take minutes before the movies started, and it would occasionally pause to buffer more. Nevertheless, it was acceptable. What was notable was that the service was rolled out with a Customer Feedback mechanism. Customer feedback was important from the very first iteration and this should be the model for every software product development initiative: listen to your customers at all stages!

Software Development has borrowed a lot of ideas from Product Development, from market research, to design form factors, to user experience and feedback, even though the most commonly used software development and project management methodologies, like Agile, don’t explicitly mention this. Yet, some software teams don’t have a User Experience (UX) position as it is difficult to justify the cost to some business owners. In such projects, change requests and feedback come from business owners and the success of the product depends on how well the business teams know their users and customers.

Customers and users (voice of the customer) should be the driving force in product development. Businesses that focus more on customer and user needs do better than those that focus more on top line and bottom line. But product ideas don’t necessarily always come from customers. Most product ideas come from business owners, but also from sales and marketing, as well as designers and technical teams. This paper focuses on the values of a Product Development Mindset when developing software.

Product Development Mindset

How do you build software applications with a product mindset? A product idea comes from knowing the users’ needs or wants, understanding the market, and recognizing the competition. In some cases, a product can be successful even if there is no real need for it. Instagram was born when Apple introduced image filtering APIs to the Core Image library in iOS. Before Instagram, people were sharing unfiltered digital images and still enjoying it, so there was no real need for it.

But what does it really mean to have a product development mindset? Naturally, a product begins with an idea to solve a problem. And there can be many solutions for a given problem. So the goal is to pick the right idea, that bears least risk, and produces the most desirable outcome. In other words, it’s about objective (best outcome), discovery (right idea) and delivery (costs and risks).

The table below shows the different phases in the product development lifecycle when it comes to software.

Table – Software Product Development Phases

The initial phases focus on discovering the right product idea, identifying risks, and validation of the users and markets. Phases 5, 6 and 7 focus on delivery. And finally, the desired outcome is achieved in the last three phases. The earlier user input is incorporated into the lifecycle, the higher chances are for the success of the software or product. The above lifecycle has multiple user touchpoints before, during, and after a product is built and launched.

Functions vs. Features

If I ask what you can do with a hammer, what’s the first thing that comes to your mind? Driving a nail through wood. That’s the main function of a hammer. You didn’t have to think about it much. But the most common type of hammer can also claw nails out of wood. That is a function of a crowbar, but a feature of a claw hammer.

Product development actively makes a distinction between functions and features. Software products are no exception. You can apply Pareto principle to software: 80% of the core functions are implemented by 20% of the code.

There is another important distinction between function and feature: you can turn off a feature, but you can’t remove a function. A double-faced hammer can still function and drive a nail through wood. But now you need a crowbar to pull the nail out.

Understanding the difference between function and feature helps with the product design and prioritization. The auction site eBay didn’t initially have a payment processing capability and to complete a transaction, most people used a third party site like PayPal or the buyer would mail a check to the seller. I doubt that the startup team of eBay neglected the payment processing capability. They just never prioritized it, or that capability was not considered a core business function until they realized how vital it was. eBay first acquired a company called Billpoint, but it was no match for PayPal, which was eventually acquired by eBay.

Great idea!

Product ideas can come from anyone who is familiar with the problem domain. Often those people are the business leaders and executives in an organization. But ideas can also come from marketing and user liaisons. Most innovative ideas come from the technical teams, specifically those with domain expertise.

We are always intrigued by new product ideas. But not all ideas gain traction. An idea needs to be validated. Will it work? Of course, there is no limit to technology these days, or at least it appears so. Will it be accepted, loved, and used? That depends. Microsoft Zune was a great media player with lots of amazing features. But it was too late. The Apple iPod was already dominant in that arena and it had influenced user opinions, where even formidable media companies like Sony were struggling.

In software development, second-system syndrome refers to when a product jam-packs tons of functions and features in the development phase and by the time it’s released, the market need has disappeared or is satisfied with a much simpler/cheaper product that users love. Is that what happened to Zune? Perhaps. But the point is, all product ideas need validation. Proper market and user research can support that an idea is worth pursuing.

In most cases, you also have to worry about your competition in the market. Are you willing to invest in an eCommerce business that serves North America? Many have tried, yet Amazon has been dominating that world. But this doesn’t stop companies from competing with Amazon in a different world, namely Cloud Computing. Amazon (AWS) is still the leader in that world, but it is slowly losing market share.

The awesomeness of an idea is not enough. There are other things you have to consider during the ideation process, such as timing, business value, return on investment, and user sentiment.

This is not to say that you need to spend lots of time and resources on the initial product kick-off. A simple proof of value, market research and focus group interviews should be good enough to validate your idea. As Richard Feynman famously said: We could never be certain we are right; we can only be certain that we are wrong.

The proof is NOT in the pudding; the real proof is in the prototyping.

Prototype

In product development, a prototype is the first time your idea comes to life.  A successful prototype will produce a lot of positive reactions and excitements. That’s the real validation that we all strive for. Because it’s much easier to create a prototype of your software product idea, many people jump to this step to accommodate market and user research.

Rapid prototyping should be your mantra. A successful product idea is validated by creating multiple prototypes.

A software prototype doesn’t have all the bells and whistles that we should see in modern applications. In fact, it may not even deal with the real data or, behind the scenes, it uses mock capabilities. But you can demonstrate the core capabilities to the users and the business owners in a tangible way, by letting users take over the keyboard and mouse and take it for a test drive and this will help with the validation of your idea.

Your prototype should capture the core essence of the product idea. It focuses on core “function”, not features; think Pareto principle. When building software products, you should have a prototype within days and weeks of the ideation step. That is a realistic goal given the wealth of available open-source libraries, SDKs and other baseline design and reference architectures. The goal is to prove value.

When prototyping, cautiously but always engage designers. Designers can contribute to product ideation. But some designers tend to begin with their vision of the final product. The experienced designer will understand the scope of a prototype and only focus on core functions that prove value. For example, the screen size and screen rotation are important form factors for mobile application development, but you don’t have to accommodate all different screen sizes and rotations in the prototype.

And this is the time for user feedback. Brace yourself! And keep an open mind. Be prepared for criticism, be prepared to make compromises or even abandon the product idea altogether after the prototype phase and user feedback.

Product Management

When a product idea is successful, everyone wins. But when it fails, the Product Manager takes all the blame. That’s because a product idea cannot be realized without a Product Manager whose role is considered vital by the CEOs of product companies. A good Product Manager is an expert in the business domain, understands the market and the competitors well, is familiar enough with technology and the technical capabilities of the teams, and can recite the organization’s goals and strategies verbatim. If that’s not enough, a Product Manager also needs to understand finance and risk management, as well as having a proven track record. And finally Product Manager scouts for the right team.

The Product Manager owns the product roadmap. The product roadmap is not the same as the project roadmap. A product roadmap lays out the discovery and delivery plan and milestones. It  focuses on functions and features, continuous idea validation, continuous market research, continuous user feedback, and maintaining a risk registry. 

Your roadmap should also be iterative. Identify the core functions that add the most value to your product, develop the capabilities, and launch. The success of your initial launch depends on how well you identify the core capabilities with the highest ROI. Continuously resist the second-system syndrome.

The tools used by product managers are not always the same as the ones used by project managers. Some tools are used to collect user feedback (like survey tools, chat bots, google analytics), some are used to develop ideas and make design decisions (like a mindmap, wireframe tools and flowcharts). A product manager also uses project management tools, like JIRA. For example, the epics in JIRA are typically owned and defined by product managers. Epics can also be owned by users, who will then also create User Stories. The Product Manager should either act as the product owner or the user advocate, a person who always knows what the users would want.

While the Product Manager owns the capabilities and the problem domain, he/she doesn’t own the solution implementation. Software designers and developers are responsible for implementing the solution. Your next challenge is to identify the right team to implement your vision.

The Right Team

Behind every successful product launch sits the right team: product manager(s), designers, project managers, architects and developers who understand the business domain, the strategic goals, and empathize with the users of the products. A developer who trades stocks and understands the language of the financial world is a much better candidate for building a brokerage application.

It is important that the product team is inspired and committed to the product idea. They must believe in the product vision and have a seat at the table. This is especially important for the technical team. The developers need to feel empowered, and be treated as if they are missionaries, and not mercenaries.

A team of software developers should have the fundamental knowledge of a business domain to be successful. It’s okay to learn on the job, as long as the desire to learn the new business domain exists and it is not left for after hours or the weekends. It’s your job to learn the business you are trying to serve.

One very effective way to capture business knowledge is by creating Enterprise Architecture (EA) models. One of these models is business architecture which documents core business functions, processes, services, activities, business goals, and strategic drivers, among other things. EA models are also used by the development teams to earn the trust of the users and the product owners. They show how well the team understands the business goals, strategies, capabilities, stakeholders, and users. Other EA models, like Technology Architecture, can help with the roadmap, resource, and cost assessment.

Once a team earns the trust of the business stakeholders and the users, it’s ready to deliver. Nowadays, most teams follow Agile methodologies which have inspired popular practices such as DevOps, Test-Driven Development, Continuous Integration, Delivery, and Deployment (CI/CD) as well as architectural patterns such as microservices or serverless.

These practices and design/architectural patterns were driven by one important Agile principle: Embrace Change!

Change is hard

Indeed, change is hard, but what is worse is inaction and lack of decision. The right mindset is to embrace change and be ready to discard an idea and quickly validate a new idea. Luckily, it’s much easier to do that in software product development than it is in manufactured products. You don’t have to recall your code; you just have to be able to deploy a newer version of it quickly. How quickly can your team add a new field to a web form to collect some additional information like place of birth? The answer should be minutes or hours, and not “weeks”.

After the launch of your product, the voice of your customers should be more important than the cost of customer acquisition. And this is the time to be prepared to react quickly to and embrace customer feedback. This is especially important during the discovery and prototyping phase.

In some cases, you’ll need to look for an advocate in your user base to promote the adoption of the product. Hopefully, the product advocate (or the marketing team) has been engaged since the beginning, when they advocated on behalf of the users. So now, the then user advocate has to become the now product advocate. Because after all, most of the ideas and user experience knowledge came from the user advocate to begin with.

What’s next

If you have made it this far, you are likely inspired to start approaching software development with a product mindset. In some cases, it is easier than you might think, especially for new software products. A small project or product might be a good starting point for thinking of software as a product. By doing that, you can establish certain practices, identify tools for collaboration and feedback, and define the criteria for choosing the right team and finding product advocates for your marketing strategy. In an upcoming paper, we will discuss how an existing team can adopt product development techniques for existing and large projects. We will also discuss how adopting a product mindset impacts the software design and architecture.

References

Sutton, Mary-Rose, “7 Step Product Development Process Explained.” Shopify, 25 Nov. 2022, www.shopify.com/blog/product-development-process.

Babich, Nick, “How to Use an Empathy Map in the Design Process.” Shopify, 17 Nov. 2021, www.shopify.com/partners/blog/empathy-map.

Cagan, Marty. INSPIRED: How to create tech products customers love, 2nd Edition. Wiley, 2018.