Are you at the head of an expanding business or maybe handling digital solutions for a company that can’t agree on their next feature regarding their store? Differences of opinion or lack of clarity might arise during business operations. Especially when it comes to websites and WooCommerce stores because not everyone possesses the knowledge to take ownership of the process and foresee what’s best to be done next.
Things like what features might be required by your WooCommerce store in the future can really cause multiple opinions to crop up.
So, how can these issues be handled by businesses owner in a productive and effective way? How can you be sure you’ll be developing a new feature your users will need?
Let’s dive in!
Deciding what the next feature should be is a journey, not a one-stop trip
When it comes to choosing technical aspects of expansion or customization of your WooCommerce store, it is important to know where your resources will be better invested and spent on. To do that, you should treat and think of your new desired feature as a product on its own and then follow business development best practices.
Specifically, it all starts with what’s usually called a “discovery phase”, a crucial stage at beginning of your process that will provide you with insights on three important aspects:
- Business and target audience needs
- Solutions evaluation
- Project scope, duration, and costs involved
These steps allow you, and anyone involved in the decision-making process, to be able to have a clearer picture of your current situation, while also enriching it as the project advances and starts shaping up.
These three subsequent phases of the process give you a deeper understanding of what’s possible to achieve given your current situation, time constraints, budget, and business goals.
Phase 1: Target audience needs analysis
The first stage of the process involves a detailed discussion on the changing business dynamics and core business operations. It all boils down to how your WooCommerce store operates and what you and other stakeholders see that’s needed as a new custom feature. More often than not, people have different ideas on what new features should be added first to their websites.
That’s where a target audience needs analysis comes into play. As WordPress developer and Codeable expert Paul Cohen explains:
In terms of understanding the business and target audience needs, business partners might have different directions on this. That’s why, before moving any further with the project, the client and I need to talk through those to understand the problem, what are the pain points your users are having, and determine what the business need is out of that. It’s like an onion: we keep going down layers and layers. And it’s not one direction, it’s a bi-directional process because is this questioning process that sparks ideas in you and your partners as well.
If you hate wasting your money – I know you hate that-, you’ll need to do your own part as this is a very collaborative process, made of continuous iterations. It can be quite an involved process because it takes time for the developer you hired to question you, your partners, and anyone involved in the decision process.
But it’s not just with some questioning that the developer’s job ends. They also need to absorb your information, do some research, and then come back to you with an MVP solution to test out.
It’s a discovery process and, inevitably, questions will play a major part in it. This constant inquiring between the parts involved allows not only the problem to emerge more prominently but other elements too like potential costs, resource limitations, technical debt, and the like. As Paul highlights, you might be asked different types of questions both about your target audience but also about your desired new feature:
Along with how painful is your target audience problem, we need to know: what’s the cost to solving that problem? What’s the cost if that problem persists? Is it an operational cost, a profit cost or is it personal cost? And then looking at the future: what would the future look like if that problem was solved or alternative futures?
There are different questioning processes, frameworks, and mental models a developer could use here to find the answers to these questions. For example, they could use a deep formal framework like Jobs-To-Be-Done, a process like Design Thinking, or even a simplified Q&A process that focuses on the business problems, triggers, and customer pain points.
On a higher-level, this phase allows business owners (you), and the developer working on the problem, to obtain ideas and proper feedback as to where things are really heading and what the next set of actions is required. Don’t think of it as a quick call, with little to zero value. Actually, it’s the opposite.
Phase 2: Solutions evaluation
Once the problem has been determined, you and all business partners (if any) can then kick off the next phase and start seeing what solutions are feasible. That starts by evaluating what are the current solutions available on the market. As Paul points out:
After you have the basic problem down, the pain points in the business side, you need to move on to the solution evaluation phase. This step involves looking at existing solutions: do any existing solutions exist? If so, how do they address your audience’s pain points you want to address through your new feature? How well do they fix it?
With this further research, you and the developer will perform a gap analysis, a thorough evaluation of how current solutions work and address the problem you’re trying to solve, then compare them one another, but also against your proposition as well.
Buy vs build decision
When it comes to WooCommerce development (and with WordPress or development in general too), there are two types of approaches you can choose from: buying a solution “off the shelf” or have one tailored and customized to your specific business requirements. Current solutions are evaluated from the four perspectives of:
- Business
- Design
- Development
- Operations
Some factors that could influence your decision are:
- Does the existing solution fit your product/service?
- What are the initial costs and ongoing costs of that solution?
- What frictions are there in terms of developer communication?
- Who’s developing that solution?
- Is it an API-based solution or is it a plug-in solution?
By going through these questions and research process, together with the help of a developer, your goal is to understand whether the costs and ease of customization of a current solution outpace what would be requested by developing your solution from scratch.
This workflow and approach to project management is useful even for more technically advanced and highly customized solutions because, deep down, you’re developing a solution to a problem, a technical solution, and here it’s even more important that you are fully aware of what you’re trying to achieve.
Phase 3: Project definition and scoping
As the picture becomes clearer and shapes up, you and the developer will have all the ingredients to scope your project on. Whether you’ve opted to customize a solution already available and developed by someone else or develop one from scratch, you start defining what you’ll need to get done.
You should know this already: it all starts with your project brief. Learn how to craft an extensive and informative one, how to make it even more useful with additional resources, but please pay attention to using expressions that are total red flags to developers.
Thanks to a well-crafted project brief, you’ll also have all other pieces of the pie ready for: milestones, deadlines, timeline, and a budget all lined up.
Wrapping up
It’s not easy to know what the next feature of your WooCommerce store should be. That’s because you have ideas, your business partners have their own, your budget might seem tight, or simply you’re pulling towards one direction and your co-founder pulls the other way.
Believe it or not, from a business perspective, all of this doesn’t count. Why? Because the most important information that should drive your decisions is missing here: your user needs and their feedback. That’s what should dictate your next move, thus what you should be developing next. Here you’ll see the value of this discovery-based approach, where notions like Minimum Viable Products/Experiences, iterations, and user feedback have all their roots in.
Through such question-answer types of processes, you’re testing and clarifying assumptions, whether coming directly from your or from any of the stakeholders. What’s important, though, is that your testing and criticizing assumptions, and hypothesis to make actionable decisions based on real data, not just ideas.
This blog post features Paul Cohen, a hands-on technology strategy consultant with 20+ years international experience on a variety of projects including WordPress, Enterprise IT, web/mobile applications, eLearning simulations, educational apps/games in teams of all sizes. He’s also a creative technologist who understands the business, product, project, design, and development aspects involved in taking ideas from concept to realization.
Dream It
