In this article, I will be sharing the behind-the-scenes of building and improving our own product development process that revolves around collaboration, feedback, frameworks and best practices.
At Storyteq, we’ve always focused on building a product which our customers value and love. But while there are many elements involved in successfully building a great product, it all boils down to a series of decisions. Continuing to meet this goal as we grow means constantly re-assessing how our team works to keep performing at our very best.
There are many ways to unpack product development, but the approach involves a few elements at its essence. I hope you find this useful, no matter your industry or size.
Start working on your solution by understanding the outcomes
The product development process rarely resembles a straight line. In my personal viewpoint, once you have an idea, you treat it like a verb – the action you need to take to accomplish a goal. The “how” you are going to do it is the solution.
Take for example, the idea of going on a trip to the Caribbean from The Netherlands. That’s the plan to go from A to B, but how to get there is composed of a variety of options. You can go by plane, cruise ship, sailing boat and if you’re crazy and brave enough, a kayak.
All of these ways have different limitations, durations, game-plans, costs and maybe even additional skill sets have to be included (third-party applications), but it’s all about assessing the pros and cons of an option in order to make an optimal decision – it’s all a balancing act.
“Products go through a continuous cycle of improvements by fixing issues and/or implementing new features that will help the product in the grand scheme of our users.”
Maki, Product Owner at Storyteq
That same approach should be seen when it comes to product development. You can have a variety of options but it’s all about discussing what the outcomes are so that we reduce any type of limitations and/or contingencies. That is when the solution arises.
The “aha” moment when defining a solution happens when the developers discuss the requirement, and filter out the options on how to execute the tasks.
There are an array of techniques on how to accomplish a task/requirement hence the crucial aspect of the team discussing the possibilities, and from there, narrowing down the best and most optimal technique to implement.
Tap into agile and scrum methodologies
We already know that companies like Apple, Microsoft and IBM are using agile product development to achieve speed, adaptability and user value. But it’s not just them: according to the KnowledgeHut’s 2020 State of Agile Report, 95% of organisations have adopted agile in some of their teams.
At Storyteq, the agile process is also central to how we deliver products. It’s a framework that has allowed us to develop rapidly through incremental improvements, iterate quickly upon feedback and steadily develop.
We have spent years building a great product, and needless to say, the decision-making process has evolved as our company has grown.
We currently work in a scrum framework with agile practices, which is more or less the most common methodology when it comes to software development.
The Scrum Guide emphasises that scrum is essentially a holistic process theory where the team would have to pick and choose what works best for them.
Like any new process, in the first few months I started working at Storyteq, there was a lot of trial and error into finding how we, as a team, work best. We would adjust ourselves into using the scrum framework as a guideline to help us streamline our working mannerisms, yet we did it with ease.
While it took us some time to really find our ground and observe what works and what doesn’t, this transacted into how much the team can really work well with each other and the adaptability towards the agility of how we work.
Keep prioritisation in the spotlight
My position is tangled in a web of different departments so I use a clear framework for the decision-making process:
- Gathering all the information from the sources
- Scheduling weekly meetings with stakeholders through our scrum events as well as our monthly roadmap meetings
- Ensuring everybody from the top down to the team are on the same page regarding product expectations, priorities and plans.
My job is to be on the receiving end of the information that is given from multiple sources, but I need to provide them with that opportunity and platform to do so or else neglect will come into play, which is every Product Owner’s nightmare.
If you choose not to give your pillars a time and place to express themselves, you’re known as a “distant product owner”, and that is a word you don’t want to be associated with in your role.
Next comes the fun part of my job, and I like to call it the “gladiator showdown”. I typically break down this process in a few steps:
- Gathering the tasks that are deemed with the same priority that obtain more or less the same amount of duration and complexity points
- Laying it out to the stakeholders so they can “fight” for their tickets that they deem a higher priority than the others
- After each sprint planning session, the scrum team defines a sprint goal that we want to achieve after the sprint ends, and I just need to remind the team to express whether or not we can accomplish it.
If we are not able to do so, agility and adaptability comes to play so that we can manage the expectations.
As we are growing faster, being more selective towards which tasks we should and should not do (for now).
We are becoming more self-aware as to what our products provide as a service, and with that we are more aligned with what Storyteq’s capabilities are, being able to distinguish more of its own strengths and where improvements lie ahead for its future.
This process has unveiled how collaborative we are when there is no hierarchy being established amongst us. The only areas of expertise are being defined but that’s natural working with developers.
Use the problem-solving technique 5Ws and H
In parallel to our agile/scrum process, I always go deeper and ask the questions of Who, What, Where, How and Why.
The “why” really helps me break down the value of why we should implement a feature, and to gain more insights on the requirements coming in from the stakeholders.
Oftentimes, after I repetitively ask “why”, the counterpart will reply with “because I want it that way” which is not sufficient in product development. We are not building something for a particular person, we are building a product for all our users.
I also try to put myself in the user’s perspective and see what job needs to be done (JTBD) when we implement such a feature.
It’s easy for users to say “I want this” or “I want that”, but essentially speaking, you always have to ask the question: “By changing or implementing something to our platform, what job does it help the users to accomplish?”
Have a rhythm for using feedback as your building blocks
In my experience, I’ve noticed that too many product teams make the mistake of working based on assumptions and outdated knowledge about their users.
If you’re serious about continuously delivering value, you have to be just as serious about deeply understanding your users’ problems, processes and goals.
“I believe that feedback is key to making our product better, when it’s given in the right place, at the right time.”
Maki, Product Owner at Storyteq
As a team, we believe great things can happen when you understand your customers’ problems, which is why user feedback is a big deal to all of our teams – it’s really integral to what we do and how we build.
At Storyteq, improving the product is at the heart of everything we do. If we can make our customers’ experience better, faster and more engaging, we know that they can be free to focus on what you do best—creating.
While feedback is imperative to the product lifecycle, there must be a balance as to what is being expressed from the users. In general, people are more likely to express their complaints rather than give praise, and that’s what we need to understand when we approach the feedback given.
It’s quite apparent whenever a triple A software company releases an update to their product, there are more complaints being passed around on how users preferred the previous version. But in all honesty, when the previous version was released, users complained about the older version being better – it’s a never-ending cycle of not being able to satisfy all users fully.
That’s why asking questions really helps dissect the sense of urgency towards the feedback given such as:
- “Is this causing the user to experience a bottleneck towards their workload?”
- “How many users/clients are experiencing this same issue?”
- “Is this making the user experience inept by having them utilize multiple workarounds?”
We need to understand the severity of the feedback given so that we can evaluate the response time towards it. Products go through a continuous cycle of improvements by fixing issues and/or implementing new features that will help the product in the grand scheme of our users.
Shared learning and collaboration: Open up the silos
As a Product Owner, I act as a bridge between the business and technical side of our company. This means that I must be extremely candid and communicative amongst different departments.
Sometimes it’s a tough pill to swallow, especially towards the not-so-great news, but transparency is key, and through that you are able to manage expectations from a grounded perspective.
Other than that, I follow a list of values which are:
- Not being afraid of being a no person within reason
- Upholding a bird’s eye view to look at the bigger picture
- Conveying objectivism by asking questions
- Fostering collaboration within my team
It’s important to push and expand my team’s technical horizons. I want the developers to challenge themselves by presenting them with tasks that are tapping into their discomfort zone. This really amplifies their product familiarity and helps infuse a creative flow.
Of course, I don’t throw them off the deep-end without having them properly onboarded with the components, and I always gain clearance from the developer if they feel comfortable challenging themselves with the given task. Consent is crucial.
These exercises are crucial to the performance of the product and the team. They unveil an opportunity to challenge each other and learn and they offer a space to surface misalignments and work towards correcting them.
Wrapping up
Product development requires a relentless focus on cohesion and clarity. You have to do whatever it takes to define a version of your product which can deliver value, ship that to users and get the iteration flywheel spinning once again.
If you liked our article, please subscribe to our newsletter below. We only send emails once a month.
P.S. We are always hiring. If you’re inspired to join our journey, feel free to check out our open roles.
