Eight principles to live by for today’s Product Owner
Combine the best of Design Thinking, Lean and Agile to create products people will love
- By Bobby Sequeira
Great technology products can certainly be a lifeline to society right now, and as we adapt to a new online normal there are plenty of opportunities in the product creation space to solve many of the world’s problems.
The tricky part for any product development team, however, is the sheer overwhelming array of methodologies to choose from before they get going in creating a tech product — whether it’s an app, or software, or other tech tool for people to use.
I’m here to help. I believe if you combine the three excellent methodologies of Design Thinking, Lean and Agile, and you follow the eight simple principles I have set out for you in this article, your product design experience will be much better, more fun and your products will be far more impactful.
Part 1: Let’s look at our building blocks
If you’re like me and my team, you might start a project by asking yourselves some tough questions, like:
- What problem are we solving and who are we solving it for (users, customers or both?), or what industry do we want to disrupt?
- Who is the actual decision-maker of this build — the CEO, the product owner or someone else?
- What role should engineers play in the design process?
- Should we use OKRs (Objectives and Key Results) to measure the outcomes of our outputs?
- How long to get to market and what are our timelines? Should we do “standups” and be “agile”?
- Will we create a Minimal Viable Product (MVP) — and do we even understand what that means?
- How do we discern the overwhelming number of product development methodologies out there?
I’ve done a great deal of research and practical trial and error to answer these questions, and what I’ve learnt is that there is value to be had in various methodologies. We don’t have to choose one over the other. We can take the best from each to achieve agility in modern product design — as long as we place principles and people above processes. I recently coached a bunch of web developers, UX/UI designers, Scrum Masters and entrepreneurs on how to do this at our IO Powwow Meetup event, and now I would like to help you.
The three key product development methodologies we’ll focus on now:
1. Design Thinking
Design thinking is a “cognitive, strategic and practical method of processes to come up with product solutions”. With this methodology, you must define the persona of the user to know who you are designing for, then empathise with the users and their challenges, then define their needs, then ideate as many possible solutions as you can, then build a prototype of some kind, and finally test your prototypes with real users for their feedback and interview them to see what they think. There are all sorts of ways to gamify and simplify the process.
One of the most famous approaches to design thinking is the “design sprint” as pioneered by Jake Knapp of Google Ventures. This method allows teams to solve product problems in a workweek, with mapping on Monday, sketching on Tuesday, storyboard/ deciding on Wednesday, prototyping/ mockups on Thursday, and testing on Friday.
2. Agile
The Agile methodology has become quite mainstream since its launch in 1991 and was popularised by the likes of Spotify in their Agile product ownership videos. It is still evolving rapidly today and remains the antidote to the traditional “waterfall method”, which dictates that the process starts with the client dictating the perceived requirements, from where it goes to the designers, then onto the developers, and then to internal testing — with users never seeing the product until it is launched. If the product fails, you have to start from scratch.
The famous Agile Manifesto promotes the following values and is core to the eight principles I want to share with you:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Its followers value the items on the right, but value the items on the left even more.
With Agile, you start with “user stories” that you put into a “backlog” of ideas to be explored in team sprints of anything between 1–4 weeks. In this process, you work in chunks of time and release small parts of the product to your users to test after each sprint. It also gives the client a chance to play with something tangible as you create it. But fundamentally, it allows the product team to keep iterating and adapting their ideas — through a rapid process of define, design, test, analyse, deploy, repeat — instead of having to go through the whole process only once, only to find out far later that your users don’t even like the finished product.
3. Lean
The Lean Startup methodology, as pioneered by Eric Ries, is a methodology for developing businesses and products that aims to shorten product development cycles. It helps teams through hypothesis-driven experimentation and iterative product releases to rapidly discover if their proposed business model is viable. Ries calls this “validated learning”. “Fail fast and try again soon” is the name of the game.
With the lean model, teams look at what the smallest possible version of the product is that they can build and test. This is called Minimum Viable Product (MVP). This could be a simple sign-up page to test how users react. You always prioritise quality over quantity, and efficiency over variety, and follow the three very important steps of “build, measure, learn”, on repeat. You measure through data, and learn from it, to adapt what you build while you build it. Lean adds brains to your Agile process. It’s a great model that you should introduce to your clients.
Part 2: Let’s explore the eight principles that will boost your product design process
Our key goal is to place principles above processes, so this is how we’ll do it:
Principle 1: Treat your project or product as a business
I often hear web developers saying that they’d love to do a side-project and they think that the software they want to build is going to be the product. But you also have to think about the operational implications of a product and whether it makes real business sense.
On the first day of your design sprint you’ll be asking yourself, “where do I see this product in three to five years?” and then you start by setting targets upfront. You need to develop a viable business plan.
I find it very useful to use a business model canvas to map out market fit, business risks, supply chain, value proposition, who your customers are and what their unserved needs are, and other elements. Once you’ve done that you can determine if the product is an app, website or something else, and where it is going to live, and what your business is all about. Then you start working on the user experience (UX) and user interface (UI) design to manage what the customer’s experience of the product will be like. You also need to check if you’re designing for an internal user or external customer, or both (think Uber drivers versus passengers). You also need to see if you’re on the side of the team that is working more on the problem or the solution.
You can also apply the 5 Ws and H to see if your tech product makes sense:
- Who is the user?
- What pain-point to we want to address?
- Why are we building this?
- When shall we deploy?
- Where shall we release the product?
- How do we go about building and maintaining the product?
I find Dan Olsen’s “Product Market Fit” pyramid pretty useful too. Olsen says you need to start at the bottom and first identity who your target customers and users are, what their unsatisfied needs are, how you are going to solve their problems, then you build your value proposition and feature set, and focus on the experience you want them to have with your product.
Principle 2: Test your high-risk hypotheses
You want to focus on things that actually matter. To do this you need to write out a hypothesis/ problem statement:
We believe that [doing x]
For [x people]
Will achieve [x outcome]
We’ll know this is true when we see [the market’s feedback].
You need to ask yourself: “what do you need to learn first?” Product teams are very busy people, so you don’t want to waste their time testing pointless features and items. So, what is the least amount of work you need to do to build something that is of high value and low risk?
How do we test? You run experiments. Dan Olsen says you have to look at what opportunities will yield the best opportunities. Another great model to use is the Kano model
to see what business ideas and product features will excite and fulfil customers the most, and what others are not worth pursuing.
Principle 3: Customer value = business value
There is a ton of competition out there, so you have to be sure you are building something that customers really need. So your approach needs to be people-centered instead of feature-centered. To be “done” is no longer about finishing the product, but rather about how your users are interacting with it.
As Marty Cagan says:
“Good teams solve problems, they don’t just create features.”
Principle 4: Teams over processes
You need to take the time to look at your software team. Normally this would include a product owner, a scrum master, your web developers, UX, business analysts and QA or quality assurers. You need to ensure that your team is cross-functional and brings something to the table, and that you DON’T have siloes. Small, dedicated, cross-functional teams create the best solutions. Some experts say co-located is best, but in the age of the Covid-19 Coronavirus we will need to adapt and figure out how to empower our remote-working teams. Whether you work in the same room or remotely as a team, conversations matter, and your scrum master needs to drive this.
Principle 5: Retrospect regularly
Our scrum masters need to ensure that our teams are always doing retrospective team discussions, to ask questions like:
- What could we have done better?
- What are we not doing well?
- Where can we improve?
- How can we create a safe environment where everyone can be open and honest?
I quite like the “Radar scoring” or “Starfish” methods:
Principle 6: Work in short cycles
Working in short cycles fits nicely into the Lean and Agile methodologies. What you do is inspect and adapt, over and over again. If it’s not working, you pivot.
Principle 7: Do less, more often
Don’t waste time on initial massive discovery upfront. It’s better to test just for two weeks and if it doesn’t work, to move on, instead of doing months of testing upfront. I like to remind my team about KISSS (keep it simple, small and short), and to learn as fast as possible.
Principle 8: Keep learning
Dive in and learn as much as you can about this stuff. There are so many great resources out there. You’ll see, the best thing about the Agile community is that they are so keep to share. Join webinars, coaching circles, and make a study of what other people are doing.
If you do these eight things you will achieve modern agility in your product design. This means you will learn to make things that people love and use, and you will achieve both a sense of fulfilment of purpose and a degree of commercial success — and that’s good for everybody.
To give credit where credit is due, the principles of Design Thinking, Lean and Agile have been inspired by some amazing product thinkers, such as:
Jeff Gothelf, author of “Lean UX”
Marty Cagan, author of “Inspired: How to create tech products customers love”
Eric Ries, father of the Lean Startup movement
Dan Olsen, author of “The Lean Product Playbook”
Jake Knapp, author of “Sprint: How to solve big problems and test ideas in just five days”
David Kelley of IDEOU who first marketed “Design Thinking” as a methodology
Take the time to give each of these amazing thought leaders a proper Google search!
Bobby is a certified Scrum Master with a heavy background in operations. Follow him on Twitter @bobbyrgs or Linkedin @robert-sequeira-cape-town/
