At Scalable Path we recommend following the Scrum methodology. Improving this process within the development team is something that is frequently thought about, but it’s also important to consider how a client, who often has the key role of the the Product Owner, can play their part more effectively within the team.
MEET THE PRODUCT OWNER
One of the more important scrum roles is that of the Product Owner. Although the title “Product Owner” might be a bit confusing, and other titles such as “Project Owner”, “Technical Product Manager” or “Customer Advocate” might make more immediate sense, the fact is that within the Scrum framework, the term everyone uses is “Product Owner”, so we’ll stick with that.
The Product Owner role is important because he or she represents the business, customers, or users, and guides the team toward building the right product (not just any product). They might be in marketing or hold a number of roles within their company. They may be the founder of a startup. Most importantly, they must have an understanding of the product’s users, as well as the business needs the product fulfills. They are the liaison that communicates the product vision to the development team.
In addition to simply being available to the dev team to answer questions, there are three things that a great Product Owner must do: Put in the Time, Prioritize and Communicate effectively.
PUT IN THE TIME
Being a great Product Owner takes time. You need time to research, think, attend meetings, explain your vision, prepare user stories and specifications and be available to answer questions. I think it is safe to say that it takes at least 25% of someone’s time (at least 10 hours/week) to be a great Product Owner on a small project. Large, complex projects can be a full-time job for a Product Owner to manage.
The most important thing a Product Owner must do is set the priorities for what new features and bug fixes should be worked on next. In Scrum, we have the concept of the Product Backlog which is a prioritized list of features that the software should have. The Product Owner’s number one job is to make sure that this list has the most important features in it and is prioritized properly so that the software will provide the optimum value to its users.
Use Data to Drive Product Decisions
When deciding which features are to be built, it’s important to back decisions up with data, be it qualitative or quantitative.
For example, if you want to build an exit overlay with the goal of increasing conversions, you may want to validate this decision by finding studies or evidence that show the effects of an exit overlay on user behavior. If there is not existing data to be found, you might consider using A/B testing to validate a decision to see if your change had the desired effect.
Another great option is getting feedback from real users, Product Owners can recruit their friends and colleagues to give feedback on their product, or when this isn’t enough, services like User Testing can help (often quite affordably) to gather information from users about their experience with your product.
Additionally, products like UserVoice allow real users of your product to report issues they are having or make suggestions about what features they would like to see added.
Lastly, tools like Google Analytics, MixPanel, KissMetrics, RJ Metrics and Inspectlet that provide data and analytics on user behavior that Product Owners can use to inform and validate their product feature decisions. When data isn’t available from tools like the ones above, the development team may be able to provide server log data to the Product Owner to find information about user behavior and application errors.
Most startups have limited funds and you definitely don’t want to spend precious money building features that you think your users want, but don’t actually provide value. Therefore, it is important to do your research and choose the priority of features in the backlog carefully based on the best data available.
Prioritizing your desired feature set properly is the first step, but without clearly communicating your vision of these features to the dev team, you may not end up with what you had in mind. Here are some techniques (from less technical to more technical) on how to better define your features so that your developers get things right the first time.
Write Effective User Stories
User stories are usually short and simple descriptions of a feature that needs to be implemented. They are told from the perspective of a customer or a user of the system. A user story can be written like this: “As a [type of user], I want [to do something] so that [benefits]”. The important thing is to keep it simple so that anyone who is picking up the story understands what’s being delivered. An example of a user story for a blog site might be:
As a reader, I want to see the author’s contact information, so that I can email them.
The example above is rather simple, but if you find that your user story is too complicated, you should probably break it down into multiple smaller user stories that can be implemented and tested quickly. A group of related user stories is grouped into an “epic” and may all need to be released together.
For a deeper dive, here are 10 Tips for writing good stories.
Use Annotating Tools
Usually a simple user story does not provide enough information for the dev team to implement a feature. In this case, annotations are a great way to supplement the user story and provide further definition.
When building entirely new, complex functionality, you may need to go to the next level and wireframe features.
Wireframes are like blueprints; they help communicate the flow and structure of the website or app being built. Wireframes are rough sketches that do not include the final look and feel. Key elements of wireframes include:
- Page layout
- Relative importance of page elements
- Annotations to describe user interactions
There are many wireframing tools available (some of them free) and non-technical individuals can learn to create them. In fact, wireframes can even be drawn by hand with pencil and paper and then scanned or photographed in order to be shared. However, some excellent product owners do not have the time or the ability to wireframe and may delegate this work to other team members like a designer.
Know the Database Schema
- Easy access to data about your users with queries (typically in SQL)
- A sense of what features will be easy or difficult to implement (major schema changes can be costly)
- Sharing the vocabulary of the development team will allow you to write user stories and specifications in a clear language that they will quickly understand.
Most databases can be set up with a graphical user interface (GUI) so that a non-technical person can click around and learn about about it. This, combined with read-only access, is a great tool for Product Owners and is something that your dev team can usually set up fairly easily.
Get to know Chrome DevTools
Right clicking an element on the page, and selecting “inspect element” allows you to view adjust the element’s CSS properties. With a basic knowledge of CSS, a person can fine-tune things like font size, color, borders and more. There are no more guessing games involved when the Product Owner knows how to communicate the specific CSS attributes they would like a developer to use. Here’s a useful tutorial on the subject:
Getting a talented development team working on your project is a great first step, but without an informed and committed Product Owner, the best development team can waste precious time and money working on the wrong things. Empowering yourself to be an effective Product Owner by learning how to prioritize your backlog and clearly communicate how the software should work will alleviate risks and increase the chances that your project will succeed.
For more information on how Scalable Path engages with clients using the Scrum process see our How We Work page.
What are your tricks of the trade and shortcuts to software nirvana? Let us know in the comments.