Square is easily known as one of the most innovative brands in the financial services industry. They’ve revolutionized consumers’ relationship with paying for goods and empowered millions of small businesses in the process. Within the product management profession, they are known for constantly hitting the accelerator on new product development while maintaining simple and beautiful design frameworks. At BigTeam, our design ethos has always been “smart enough for a small business” and we’re big fans of how Square has evolved its offerings while maintaining their modern and approachable design and user experience.
This is why we’re excited to bring another edition of Feedback with Professionals with Elaine Perez, a product manager at Square working on their billing product initiatives.
When I first began in Product about five years ago, the company I worked for at the time was shifting from Waterfall methodologies to Agile. Part of that change included moving away from a structure of separate departments for Engineering and Product to one that unifies and aligns both groups to build the right software for customers. That alignment from a structural perspective is something I would recommend looking for in any Product role. More recently I’m seeing more formalization around customer-centered design to better ingrain these ideas into development with methodologies like Jobs to be Done, and an emphasis on the balance between Engineering, Product, and Design as opposed to the “Product Manager as CEO of the product” concept.
Using a framework that absolutely depends on external stakeholder input and customer interviews will help you identify and understand what your customers want to accomplish. Any internal team that interacts with customers, including support and sales, can provide valuable insight as well. It’s best to keep all of these channels open throughout the development process: hearing that customer voice informs your roadmap, and then course-corrects you during the development process to make sure you’re building the right thing and making the correct tradeoff decisions when they inevitably arise.
Recently, at the beginning of a product cycle, I planned for a feature that seemed like an obvious fit with the rest of the product iteration at the time. By continuing to interview Square sellers and catalog feedback from sales and support channels, I realized this particular feature wasn’t at the top of the list. However, there was another feature gap I kept hearing about, so I was able to swap them out before we spent any precious engineering time on it.
Engineering, design, product, analytics, data science, customer support, marketing, sales, customer insights, risk and security, global markets, finance, and legal–there are more at Square, but these are the areas I interact with the most in my role. I think the biggest limitation in terms of tapping into a single department more is time, both for me and for the experts to invest their time into any one product effort.
Start on time, end on time. Have a goal and make sure attendees know what it is, either with an agenda or by discussing it at the beginning of the meeting. Be willing to share conflicting opinions in the meeting itself. You can always take something offline if it’s too big to resolve, but saying nothing, or worse, agreeing when you don’t actually agree, is counterproductive. Stay engaged. One way I like to do this is by being the note taker. At Square, we use Google Docs to assign next steps to a single person to remove any ambiguity.
Another practice we use that I like is to budget part of the meeting to read any relevant documents and comment on them. That way you don’t rely on preparation taking place ahead of the meeting (which may or may not happen for everyone there) so that everyone is reacting to the same information. You can read about how, and why, we do this at Square here. Comments made in the document itself are a way to identify points where more discussion is needed in the remaining meeting time, and they are an efficient way to allow everyone to have a voice—the loudest talker isn’t necessarily rewarded. It’s worth the awkward silent reading.
Creating a document and then sharing it for comment is Square’s preferred tactic for gathering feedback on product strategy and tradeoff decisions. We often use a SPADE framework for decisions (situation, people, alternatives, decision, explanation) and Gokul Rajaram who leads Caviar, Square’s Restaurant Delivery Service, gave an interview about this framework if you want more details. A benefit of creating documents like these is that they can be shared throughout Square, so in situations where I need information or background, I can often search for and find that information on demand.
When I hear about a job our sellers cannot accomplish with our current product, it typically comes in the form of a very high-level request. “We need X.” Delving into what exactly that means is important because what I think “X “is can be quite different from the actual need. Interviews that get into the specifics with the end-customer are invaluable. Typically I begin with open-ended questions and then ask for more details, walking through their process (both whys and hows) to understand their pain points and needs.
This was one of our favorite interviews in our Feedback with Professionals series. Let us know who else you’d like us to interview!
We’ve also written about a new form of meetings happening at companies like Square, called Silent Meetings. Check it out here.