Building better products with Quip — a PM perspective

By Falk Gottlob

I've been a product manager in training for 20 years. Yep, you read that right — the learning never stops, and you can always become better. The experiences I have collected could fill a book, but there is one particular fear that has caused me to lose sleep over the years. One question plagued my mind for far too long and I could never find a comforting solution until using Quip.

"Am I really building the product my customers want?”

As product managers, it's our job to ship products that customer love. We are often the glue between different parts of an organization, and a champion for our product and its users. As a way to deliver better products, product managers always try to stay in tune with customer needs, have an eagle eye for bugs, deal with difficult cross-functional collaboration, and write better user stories which will make for a better roadmap

How does using Quip change the game?

Quip is ideal for the product management use case because it enables delivery that's both agile and iterative. It facilitates productive discussions between development team members, business stakeholders, and customers. User stories are usually the vehicle to communicate the changes required to advance the product. And the most valuable user stories are the product of meaningful conversations. Quip connects content and collaboration and will help you discover hidden assumptions and facilitate effective conversations to ensure shared understanding.

User stories are often misunderstood as lightweight requirements, given by the product manager to the developer. This misunderstanding leads to stories being collected in a task management tool, with a ton of detail written down by the product manager. This division of work prevents teams from reaping the benefits of user stories. When you passively hand over user stories — regardless of whether they are on paper, in a wiki, or in a ticketing system — you lose the power of user stories. Teams with such a process won’t get the full benefits of iterative delivery.

Creating user stories in Quip will enable a completely different model: requirements by collaboration.

With Quip, handoffs are replaced by frequent involvement and discussion. When knowledge is spread among different people, a discussion between business stakeholders and delivery teams often leads to good questions, options, and product ideas. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made. Teams that use Quip will have effective discussions about user needs, requirements, and solutions. This is critically important because there just isn’t enough time for anyone to sit down and document everything.

When only the product manager is writing and documenting detailed stories, the entire burden of analysis, understanding, and coordination falls on that person. This is not sustainable with a rapid pace of change, and it creates an unnecessary bottleneck. In essence, the entire development moves at the speed of that one person, and she is always too busy.

Quip encourages storytelling instead of dry documentation, keeps track of conversations, and reduces time wasted on nailing down the details up front. In Quip, you can engage the marketing, design, and development teams in a discussion, explore a story from different perspectives, and the result is better, more informed options. That’s the way to unlock the real benefits of working with user stories and modern development teams.

I trust that I'm building the right product because of Quip.

And there are three reasons for that.

  1. No more misunderstandings. Conversation in Quip supports product managers not only in explaining what they want, but also in checking that the developer understands this fully. Discussing a story in Quip prevents problems from falling through knowledge gaps.
  2. Faster results. When the entire team is engaged in a conversation, functional gaps, inconsistencies, and unclear requirements get discovered — much faster than when a product manager is just writing down the details.
  3. Better products. To design good products, people need to be clear on the customers and opportunities, understand the problem domain, have in-depth knowledge of technical constraints, and an awareness of emerging technologies. Engaging team members and customers in analysis from different perspectives helps the team benefit from shared knowledge. As a result you deliver better products — and better results.

Strong products are created in conversation. Quip elevates conversation.

Get started today

Try Quip with your team now — create a free site in minutes.