Bruce Mason on Product Development Process: “You need to know when enough is enough.”
by Sasha B. on Dec 14, 2022
Bruce Mason is a Delivery and UK Director in QArea. He has 30+ years of experience in software development, building big teams and fine-tuning the processes within Banking, Fintech, eCommerce, Travel, and Public Administration domains.
Bruce navigates the landscape at the intersection of project management, customer focus, and product-oriented leadership. Our editor talked with Bruce on what constitutes a quality product development process, what hidden costs can fail you, and how to spend less, with the recession in the offing.
Where does it all start? It depends on who does it
There are two options — outsourcing your product to a company like ours and building a 100% in-house product. They are similar in approaches but different concerning the roles of product owner, subject-matter experts (SME), and the stage at which you get engaged.
In the outsourcing-based model, the SMEs and the product owner will likely be on the client’s side. The product owner will, on behalf of the client, define priorities and values and state what the product needs.
However, if the product is domain-based, the outsourcing team can provide product guidance based on regulatory requirements and the current situation. I have been working in the finance market for 20+ years and guide clients about the issues they may be less versed in or forget. It is truly beneficial to have domain experts as a part of an outsourcing team. They are both aware of the latest regulations in the field and have a laser-sharp vision when it comes to industry trends.
With regard to the starting point, a product-owning side begins with product ideation and market research. Later, the company either continues working on a product in-house or goes for outsourcing. In 8 cases out of ten, the outsourcing team starts by getting market research information from clients when some groundwork has been laid, and the target audience’s need was established. The remaining twenty percent of cases cover projects where the side team is engaged at the market research stage and contributes to in-depth customer interviews and personal creation. Mostly, such services are provided by full-cycle outsourcing companies working with high-tier clientele.
A thankless job: Why a product owner needs to be a “bad guy”
First, you must have a product owner, who collects understanding, demands, and ideas based on business needs from several subject-matter experts. It is better when the product owner is not an SME themselves and don’t have a vested interest in which elements will be delivered first or delivered at all.
In both scenarios (in-house and outsourcing), the product owner manages the process and prioritizes needs and requests on behalf of the business. It is arduous because two, five, or twenty SMEs present their demands and ideas as critical and push their agenda at every meeting.
The product owner’s job is to absorb all the “I need this done ASAP” demands and prioritize among them, keeping SMEs happy and in line. The trick is giving at least something to everybody as fast as you can so all the SMEs feel included. It is exactly why you need a product owner with pro soft skills! With the power of persuasion and diplomacy, they turn edgy sharks into dolphins, jumping through all the product development process hoops.
The trick is giving at least something to everybody as fast as you can
You want investment return, thus, while including SMEs is important, getting business value as quickly as possible is crucial. To that end, SMEs sometimes have to take a back seat because key features are the priority here. You don’t have a product if you have all the frills and bits, but lack core functionality.
Product owners are not power-hungry. They just need to act on behalf of the business interests of all stakeholders.
Do the requirements down, and build the product up
Let’s look at how this is done and managed between organizations or internally. I will not go into many details, just give you an overview for a high-level understanding.
Backlog. First, a product owner with proxy product owners, for example, business analysts, defines a product backlog within Jira or a similar system. They specify all the actual items that need to be delivered, starting with what is known as the epics.
Epics — features — stories. Epic is something massive, like a payment system. A feature is smaller, for example, a payment system’s integration with MasterCard or Visa. A user story is a low-level piece of functionality. Many user stories will make up a feature, and features will make up an epic. You do the requirements down, and you build the product up to deliver the collective whole.
Rationing. A product owner, or a proxy product owner, draws down all those requirements to ensure the scrum team has enough user stories with which to work. Typically, it means that about 20% of the backlog has to be refined at a low level.
Prioritization. The product backlog gets prioritized into sprint backlogs. The sprint teams then decide which ones they take based on the business priorities refined at the previous step. Then it all gets pushed into a standard scrum-based approach.
Grooming. The sprint team works with the business analyst and/or the product owner to effectively understand the use cases that have been prioritized. Any misunderstanding at this stage costs money, so you want your development and business teams to ask many questions and give detailed explanations.
Sprint planning. What are you going to do, who is going to do it, and when will you do it? The sprints are usually longer when you start because you need to develop all the fundamentals to deliver something from scratch.
Sprints. Developers will do the developers’ work; testers will do test checklists or, ideally, test case scenarios so that they can progress to automation.
Sprint outcomes. At the end of the sprint, you have two milestones: sprint demos and sprint retrospectives. A product owner needs to sign off that the sprint’s result is fit for purpose. In the scope of a retrospective, you reflect on what was done, how, how it can be done better, etc.
Back to square one. This process is iterative. Once you close one sprint, the product owner is already speaking to you, demanding grooming for the next one. And you go around this loop as many times as you need to deliver a starting point — an MVP, effectively.
Later, you push MVP to the market and sell. After that, you increment your product, growing it larger and more efficient for your end-users.
So when is enough — enough?
There comes the time when you turn around to acknowledge that you have spent 100 000, a million, two million dollars on product development. What did you actually deliver? If you have developed 80% of your product, does it make sense to deliver the remaining 20%?
It is critical to know when enough is enough. However, businesses may not consider it or just not have enough experience to stop on time. For us, as an outsourcing team, it is ethical to warn clients about potential overheads of prolonging the product development process. We keep abreast of the process, conducting interviews and coaching-style sessions with clients. Communication is a Rosetta Stone of the entire product development process — it speeds up the process, saves money, and reveals workflow landmines that would otherwise blow up in your face at the worst possible moment.
Outsourcing ethics: Warn clients about the overheads of prolonging the product development process
Extra bells and whistles may cost another million, but will those bring enough business value? You may argue that the product is constantly going to grow. Some of your end users may argue that aesthetically some frills may make sense, and they will be pleased to see them. Unless those make it easier for clients to use your product, no extra money will come your way.
You need to stop nailing a particular product’s part at some point because it is not cost-effective anymore and won’t bring additional business value. It doesn’t mean that you will never enhance it. It means that at some point, you may have your customers pay for improved aesthetics and “may be nice to have” features.
What can go wrong? Recipes for disaster
Prioritization democracy (overrated!)
Immature organizations often don’t have a single person for a product owner role and let SMEs maintain a backlog. Letting subject-matter experts try to agree on what should be delivered first backfires immediately. In the end, all get marked critical, the delivery team is in a frenzy, SMEs insist on everything being an A-level priority… Here. You have yourself a stalemate.
As a representative of an outsourcing provider, once I see a “democratic prioritization model,” I try to fix it. Using the power of our experience, I convince clients to choose someone to be in charge. You cannot have 50 priority #1 items when we can deliver from 5 to 10 every corresponding sprint.
Sometimes, clients don’t have anyone to fit the product owner requirements or rise to the occasion. In this case, we offer an expert from our side to play this role. They don’t have a vested interest, can do well with priorities, and have domain/tech experience. It is not a perfect solution, but it is light-years better than a “democracy” game with a group of scheming SMEs at the wheel.
Garbage in, garbage out
What goes into the sprint and what goes out of the sprint is not always what the business wants to see. It often happens at the start of the product development cycle, when everyone just gets set up.
If you get wrong information in, it’s garbage, and you end up receiving garbage from another side. It is essential that what goes in the sprint is accurate and quality. You need to think about how to get better at communicating to deliver right at a low level.
In the perfect world, the product owner controls the entirety of input data and signs off on every task before it goes to a delivery team. It is a hefty weight. It is also unrealistic to expect one person to do it flawlessly in the long run in a scope of a big project.
In reality, you need business analysts or proxy business owners to make sure that the product owner is not overwhelmed, no garbage gets in, and no important specs are forgotten. They can sit in on the meetings with SMEs, gather valuable information, and ensure that all extra requirements are met.
The money spent on a business analyst in aid of the product owner is money well spent. The trust grows, and at some point, a business analyst or proxy product owner starts signing off on elements. It spares the product owner time for more strategic, value-boosting thinking and acting. Such approach covers all the holes and ensures continuity.
Waiting too long to fail
When we push an MVP, the audience may say, “Well, I don’t want a square, I want a circle now.” Because when they see a product in a working environment, it just doesn’t work for them, no matter how much communication has happened before. We just didn’t hit the client’s need close enough.
So, you return to the very top and restart interviews with a target audience, launching more precise market research. This time, product owners (in-house or from the outsourcing side) also participate in the pre-development stage, drawing all possible information from customer needs analysis and interviews. Once the new data come in, you are in the development loop again.
A larger organization that understands its processes and systems can make more significant releases. For example, a big legacy bank wants fintech to engage more with users. They know how the system works; it is just a question of putting a user-friendly front end on.
While a startup — new and fresh, something no one has seen before, needs constant checks on where and how to evolve. Big companies use MVP to show what is going on, and startups use MVP to learn and define where they are going.
Startups spend money they got in investment and need to get it back fast. Big companies can afford to spend a million on the corresponding systems, building 30-40% upfront before pushing MVP out. They are less concerned about what will happen because the functionality is a known entity, and it is just aesthetics that they’re potentially going to tweak.
Failing fast, learning quick — that’s how it should be done. No matter whether you are a startup or an enterprise, you need the right people in the right roles because the projects should be delivered quickly.
Looking for a product development team to refine your ideas into strong-suited software?
That is going to hurt: Hidden costs of product development
There are endless hidden cost in any product and project-related lifecycle, but if I need to narrow it for product development precisely, these will be my picks.
Regulatory costs
Small startups tend to forget about regulatory costs. They want to deliver as fast as possible. There is not much I can say here — you just need to follow changes in regulations and, if you are outsourcing, choose a company with strong domain expertise. They will have a roadmap on regulatory requirements and how much it will cost to develop and operate within legal guidelines.
Testing: Manual vs. Automated
As your product evolves, manual testing may become an overhead, and you may need to switch to automation. Some companies create CI/CD-based environments from scratch as an investment in a product. Others wait till they have an MVP and later play catch-up.
Automation is not cheap, but automating it once correctly is extremely efficient and cost-effective. However, if you start automation too early, it also becomes a cost overhead. The right time to automate is solely defined by how stable your product is. If your product for a specific feature is 80% stable, don’t wait, start automating. It comes to one-button regression testing vs. someone manually testing features for days, if not weeks.
Some companies can go years without investing in automation, and it is just a money pit. I stumbled upon a company building a product for three years, with 3-4 weeks of manual testing preceding every release. They didn’t want to automate because of the costs but had 3-4 years ahead to build and grow the system. Ultimately, through automation, we have cut testing time to one week, allowing faster releases and more money from the customers.
Marketing: devil’s in details
From a marketing perspective, you need the right people with adequate expectations. If you want a big event — like going Live with your launch — you want all of that PR launched in advance and in coordination with a product owner. Also, if you have a release on March 7, adding new features to develop on March 2 is bound to fail.
I have seen an eCommerce-based system that went live and neither attracted much attention, nor got enough feedback. It was very unpleasant. Later, we discovered that the client didn’t send an e-mail to their waitlist. They did lots of PR, but forgot to tell their customers they were launching. It always comes back to planning and checking — and I recommend triple checks in such cases.
The recession is coming: Where to save money in product development?
I am a finance-based guy. From my perspective, it all comes down to balancing the books — the return on the investment.
MVP: Make sure it’s actually minimal
The first way to save money is to question your MVP: What business value it brings? Which physical revenue are you going to get by that feature being there?
A good MVP consists of three kinds of features. Killer features constitute a difference — how you stand out. Target features — a specific functionality, the key idea of your product. Frills — extra features to play with, some eye candy for a user.
If you have too many frills, you are wasting money. I always work to convince clients to focus only on several components and expand later. Just think of it! Customers will do the hard work and throw change control at you through all the suggestions they make to help you create a more sellable product.
Complex products in such domains as healthcare or fintech can’t just push some mock-up of a product to the market. However, they can still create MVPs and benefit from them.
When you launch an MVP, a feature, as a collective, must work. Meanwhile, just because the system is there doesn’t mean all the tech is there. There may still be manual processes that sit behind the feature. You need to have a working solution as a whole. How much of that system is tech-based, how much is paper based, how much is done at hoc can be played with.
Outsourcing: Just cut those overheads
Hiring people full-time in Western culture often comes with additional cost overheads for employees. In the UK, we have rather strict labor laws. For example, even when you fire someone, you still need to make redundancy-based payments for some time.
Depending on what you need, it may be a good idea to hire contractors, freelancers, or outsource-based providers. If your need is small — a contractor or freelancer will suffice. However, if you have a whole piece of functionality waiting to be developed by experts, go for outsourcing.
If you have a legacy-based system in the US or UK to maintain, you are probably paying a stupid amount of money to do it. Train people in other countries, or hire an offshore/nearshore team at least 80% versed in what you do — the support costs will go down. Make sure such decisions are compliant with your SLA.
When a company is starting up, they have limited resources and don’t have enough expertise. They may not have domain- or software-based backgrounds, so they need support and guidance. Reduced costs and additional expertise synergize when it comes to outsourcing your project to domain experts.
For me, product development is about bringing all the elements together. Bringing together the right people with the tech-, business-, and creativity-based aspects under control to make the application sing and get the audience to buy and love it.
Share:
Hire a team
Let us assemble a dream team of specialists just for you. Our model allows you to maximize the efficiency of your team.
Written by
We Help With
Your tech partner needs to be well versed in all kinds of software-related services. As the software development process involves different stages and cycles, the most natural solution is to have them all performed by the same team of experts. That’s exactly what our diverse range of services is for.
The choice of technology for your software project is one of the defining factors of its success. Here at QArea, we have hands-on experience with dozens of popular front-end, back-end, and mobile technologies for creating robust software solutions.
In-depth familiarity and practical experience with key technologies are one of the cornerstones of successful software development and QA. But it also takes specific knowledge of the industry to develop a solution that meets the expectations of the stakeholders and propels its owner to success.
Ensure an effective online presence for your business with a corporate site.
