Estimation and prioritization for a product roadmap

We started our Product Management course digging into a new feature release of a School Admin product. School Admin works with independent schools to provide software that they can use to automate all kinds of school administration tasks. The release that we are working on is a parent-facing portal that facilitates online applications to client schools.

We first documented the features and then facilitated a discussion with a software engineer to get an estimate for how long the project might take. The first engineer I talked to was my friend Sunny. Facilitating that conversation, I let him organize the features into categories that were meaningful to his work as a software engineer (navigation, data management, styling, sub-pages). He then gave me estimates for each of those categories.

Afterward, as I was thinking about prioritizing features for a thin slice version of the app, I realized Sunny’s estimate wasn’t really going to help me. I reached out to another software engineer, Matt, and walked him through the features and asked him to provide an estimate while sticking with my categorization around features. The estimate ended up actually being substantially shorter (a little more than 5 weeks, compared to about 8 weeks), which I attribute to natural variation. Both engineers insist they were giving very conservative estimates.

With Matt’s estimate, I was able to think about what features seemed worth investing time in. Right away two places to scale back came to mind. First was a component to add an applying student to the portal that included a sub-component that asked to identify who this student was a sibling of. The flow of this feature seemed potentially confusing. Is step-sibling a sibling? If one parent did the application for one child last year and another parent completes the process this year, would the portal prompt this different user?

As I explained how it might work, Matt indicated that it might complicate existing data structures. The estimate for the ‘add student’ component was substantially increased by including the ‘add sibling’ subcomponent. For something that to me had questionable value, it was easy to de-prioritize that.

The other possibility I considered for scaling back was the student dashboard and the application checklist. Both of these features included a visualization of the student’s progress as an applicant. Although seeing the application progress in both screens was nice to have, they were performing the same function for the user in different ways. Twice as much work for the developers, but not twice the value for the user.

Although I had an intuition about these two features being the place to trim fat, I wanted to approach the question more systematically. I used a 2×2 to graph the value to the user against the effort required to deliver the feature or component.

prioritization chart

I then created a product roadmap for the full product. I put features that served as containers for other features first (such as the menu and sidebar). I also prioritized the fields that can be customized by the schools as they might end up needing more robust testing because the school users might get really weird is chosing content for those areas.

Parent Portal - Full Product

Visualizing the process this way I realized two things. One, the notification center icon was a substantial chunk of the roadmap. I hadn’t even visualized it on my 2×2 thinking of it as trivial. Two, while my Matt and I had discussed the complexity of the ‘add sibling’ sub-component, I hadn’t actually asked him to break down the estimate into one estimate for the component without the sibling option and with it. If Matt and I were actually working together on a team, I might have sent him a quick slack message for clarification, but because he was just helping me out with this project, I decided to work with the info I had.

My ‘thin slice,’ a scaled-back version of the product with 80% fewer resources in terms of developer time, emerged with ‘add sibling’ component intact, but without the dashboard status display and without the dynamic notification icon. The link to access the notifications is still there, but does not display differently in response to new notifications. The redundant status display on the student dashboard is removed. Now a parent will have to click on the application checklist to see their student’s progress toward completion.

Parent Portal - Thin Slice

With testing and feedback from users on both the school administration side and the parent applicant side, I might have made different choices. Will it annoy schools to send notifications that parents never see because a red blinking message icon isn’t demanding their attention? Will the lack of a progress bar at the top level screen lead to lower rates of application completion? Perhaps.

While talking to Matt and Sunny they both emphasized that the time estimate for a project doesn’t reduce by half when doubling the number of engineers on the project. Context switching and time spent coordinating work and making sure endpoints match up reduce the efficiency of projects with mutliple developers working on them. To minimize inefficiencies my roadmap suggests an order, but defers to the engineering team to allocate work within the team.

Sizing and product roadmap

In our Product Management class, for our first and second assignment, we understood how working with a developer was like. We re designed a parent portal website with the use of Adobe tools. We then found features and components inside the wireframes, we named them and numbered them to give them a category. We then added every piece of information together into an excel which we would then use to explain to our developer what are the features and how they work.

Screen Shot 2020-04-13 at 18.08.45

Doing this helped me to understand the platform and also to understand how the developers work with the information that you give them, how clear did I have to be? Was the structure and features right? A lot of doubts came to me before talking to my developer Pete, however he was amazing and helped me go through my information and explained me why he estimated the time he gave me. The best thing is when I got the estimation, he said we (designers) should always double the estimated time so no client goes crazy.

Screen Shot 2020-04-13 at 18.11.15

After having an estimate time, I used a sorting tool (must have, should have, could have and won’t have) to prioritize which features where crucial to the usability of this website. Keeping in mind that we have 2 full time developers and 5 weeks to finish.

Screen Shot 2020-04-13 at 18.11.28

For our las exercise, I did a thin slice of the project, including only 80% of what my developer had estimated, with that I got rid of almost all of the “could haves” and got a free week to deliver before. To conclude, this was an interesting assignment, the part where I learned the most is definitely when I got to chatting with my developer, getting to know how he works and what is his role like.

Creating a Product Roadmap

In our Product Management class, we have learned how to properly identify and catalog application features, as well as different sizing techniques for determining the length and workload of developing them. We are working with our instructor on an application that helps students and their parents keep track of school applications. We analyzed screens from this in-progress project, identified the features offered, and then presented them to developers to get their opinion on how long each would take to develop.

Once we had determined the time needed, we were tasked with creating a full-length schedule and a “thin slice” schedule for developing 80% of the product’s features. I had spoken with my developer about the potential for creating slimmed-down versions of some features that he informed me would take a particularly long time to develop, such as the ability to schedule school visits through a calendar function and school coordination. With an assessment of 14 days, this was by far the longest development time of any feature.

The following spreadsheet represents the full-length development schedule I’ve developed, assuming two developers are working four-day work weeks.

Full Schedule
Product Roadmap: Full Feature Development

The thin-slice version removes two features: the Schedule Appointment feature and the Prepopulated Entries feature, which would automatically recognize information about a student entered for a previous application and supply it for future applications. It also changes the Search for School by Zip Code and Distance from Zip Code features into a Search by City and State feature, which saves 2.5 days in development. These changes bring total development time from 38 days (19 days with two developers working) to 18 days (9 days with two developers working). With an extra day’s worth of time baked in, the two schedules come out to 20 days and 10 days, making thin-slice development time exactly half the length of the full version. The thin-slice schedule can be found below.

Thin-Slice Schedule
Product Roadmap: Thin-Slice Version

When assigning tasks and determining the order of development, I assessed features based on must have, should have, could have and won’t have criteria. I worked to assign developers to entire flows and to assign flow development in concentrated schedule blocks, so that the developers would not have to jump around between different screens and flows. Must-have features were prioritized first, and subfeatures were developed after the primary features they depended on. To the extent that the schedules deviate from this pattern, it was due to developer input that some features would take one tenth, one fourth, or one half of a day. Combining these smaller features to create a full day’s worth of work occasionally required combining work on different flows into a single day.

This project, while initially difficult to grasp conceptually, has proven invaluable in learning how to work with developers to appropriately size projects and create a roadmap for development. Knowing how to speak this language and translate information from design to coding is crucial for working with teams to bring products to life.

Planning Product Roadmaps

First, Feature Sizing

Throughout product management we’ve been using School Admin’s parent portal as a working example to examine and dissect an online product. We were tasked to parse out the portals’ features, down select to what features were necessary for it to be a working product, and create a product roadmap to get the minimum viable product up and running.

I began with selecting the features that I thought would be needed in order for adding a new student to be a success. I placed blue dots around things I thought would be necessary to include on a pricing document to review with a developer.

 Screen Shot 2020-04-13 at 3.23.17 PM

I later spoke with a developer at School Admin to really get the scoop on what goes into one of their pages. Clickable buttons, search entry fields, and drop down’s turned out to be the least amount of work when crafting a page. Features that took longer were things that required retrieving external or internal data. An example of this was calendar build outs. They explained that calendar functionality would have to be coordinated with outside servers. This could take an additional 10-14 days to build. A feature that is helpful, and provides convenience but albeit not something absolutely necessary.Screen Shot 2020-04-13 at 3.51.27 PM


The total build of onboarding a new student was estimated at about 50 days of production. After going over the wireframes and features together, the developer and I were able to eliminate some of the non-necessary features (like the calendar) in order to create a thin-slice. We cut off about 21 days worth of work for two developers working at 40 hours a week. Thin-slicing is the act of having the proprietary goal work, sans the bells and whistles that could be added to the site later.

Building a Product RoadmapScreen Shot 2020-04-13 at 4.39.46 PM

To better illustrate achieving a shippable product we created product roadmaps. With a roadmap, you’re able to see what features are to be prioritized during build. Throughout my conversation with the developer I was told with so many reusable pieces that I should have no trouble getting the bare bones of onboarding a new student up and running. The calendar link was

Using the MoSCoW (Must Have, Should Have, Could Have and Won’t Have) prioritization method I created the above roadmap. This forced me to exclude the link to calendar feature due to it’s intense backend link-to-external-server time.

additional learnings

I used product plan which gave an easy grab and drop box feature that would have taken added time in excel or google sheets. During this product roadmap exercise I found the ability to see tasks of highest priority take hierarchy over others extremely helpful. To be able to pass this along to anyone on a team internally or externally would eliminate confusion or constant check-in. An added bonus in the current light of remote work.


Developing a Product Roadmap


Sense making for strategy

Sizing estimates are primarily useful to product managers and business people. The estimates provide a frame for evaluating the importance of a feature, identifying level of effort and cost, and informing a prioritization schedule.

The process for arriving at a sizing estimate session includes defining features within a screen. These can be grouped by hero flow, common elements, or macro feature sets. Defining the features is a sense making activity to understand the underlying logic that supports a user’s narrative structure.

Armed with this background, we can then begin to unpack features through a prioritization framework. These frameworks function as a sense making process for strategic planning.

This, that, or the other

I started with the ICE framework which evaluates a feature based on impact, confidence, and ease on a 1-10 scale. Features are prioritized by the average of those 3 variables.

Screen Shot 2020-04-13 at 1.46.20 PM
ICE Framework + MoSCow Method

ICE didn’t seem a robust enough framework for evaluating macro feature sets, but I can see this as a more practical framework for evaluating micro features within the larger set. The 1-10 scale felt arbitrary and subjective but the exercise was a useful forcing function to then run those features through different frameworks to compare and contrast.

Screen Shot 2020-04-13 at 12.48.19 PM
Value vs Complexity Quadrant

Product roadmaps = shared ledger of truth

Roadmaps provide visibility and can function as a neutral document to facilitate conversation around business needs and team capabilities. The roadmap lays out jobs to be done, assigns persons to each task, and dictates the order in which those tasks should be completed.

Screen Shot 2020-04-13 at 2.23.49 PM
Rollout roadmap for two developers

After completing a high level roadmap based on macro feature sets, we assumed that we had a 20% reduction in resources. I created a thin slice roadmap that would allow us to accomplish the must-have and should-have features at a reduced 80% capacity.

Screen Shot 2020-04-13 at 2.24.03 PM
Thin slice = sacrificing non-essential features or could-haves

Key Learnings & Insights

  • Wireframes are a game of logic flows. Articulating the narrative structure through user stories helped me recognize linguistic similarities between designers and developers.
  • Developers are people first. I felt irrationally surprised that developer Pete was a normal human and an easy conversationalist. The mythology surrounding developers is something to be mindful of, but they aren’t a monolith either.
  • Everything is sense making. We are trying to determine all the parts that make up the whole to investigate what is meaningful and define what is essential. 
  • Screens are relatable, spreadsheets are not. Walking through screens is helpful because it allows the developer to see scope of work in relation to things they’ve done before.


Creating a Product Roadmap

Starting with sizing

Through the first half of Q4, we have spent most of our Product Management class getting to understand the role of PM’s, and how we will most likely interact with PM’s in the workplace. We have gone through exercises to estimate the time needed to complete a list of features on a product called SchoolAdmin. We spoke with developers in a 1-on-1 session (thank you Julianna!) to break down the features and give an estimate to the amount of work it might take to complete the tasks. Now that we have the understanding of time needed, it was our job to prioritize the features and create a product roadmap that leads two full-time developers to complete the project.

Snapshot of breaking down features to discuss with developers
Snapshot of breaking down features to discuss with developers


Feedback knowledge

Discussing the sizing and hearing some think-aloud feedback from my developer was helpful because I was able to grasp how they group problems into buckets to tackle at the same time. It became clear that the various stages of the “Add prospective Student” flow were all tightly connected, and that these tasks should be approached at the same time and not necessarily considered multiple jobs.  This feedback allowed me to create the roadmap in a more streamlined fashion and guide some decisions.

Building the Roadmap

image (10)

Using the MoSCoW priority method (still trying to figure out how Must Have = Mo), I broke the features into Must Have, Should Have, Could Have, or Won’t Have classifications. Trying to start with Must Have, while also making sure that the developer was working on similar or dependent features made the roadmap slightly more difficult.

The 2nd task to this project was to effectively rebuild the map with a hypothetical budget cut, allowing only 80% of the previous time allotted. This proved to be more difficult, and required decisions of making some feature Won’t Have, which I did not need to decide in the full roadmap.

Roadmap adjusted for 80% of previous budgeted hours
Roadmap adjusted for 80% of previous budgeted hours

Insights and Learning

  • Features like “Add 2nd student” that were linked to “Add prospective student” should be given to the same developer due to familiarity.
  • Features that were dependent on previous pages or features being done could not be considered “Must Have”.
  • Prioritizing building the “School info” was more critical than the “School Filter”. In a worst case scenario, a user could manually scroll through the list of  schools, where as without the info, there would be nothing to filter through.
  • Removing the “Breadcrumb”, although only 1 day, was an easy omission because there are multiple ways to navigate the site already through the dashboard and sidebar.

Communicating Insights and Design Principles for the UT System

This is part three in a series about communicating a project with the University of Texas system. Visit here for part one: introductory research or here for part two: the project brief.

Rather than tackling an entire design project from start to finish and focusing on all aspects, we are pairing down our efforts to have one goal: clear communication for client updates. There are so many nuances to learn within the design process, it’s helpful to only focus on how we are communicating our ideas. As design grows and starts ousting MBA-clad professionals as company-wide leaders, the power to communicate our concepts to a wide audience is increasingly important. 

This week’s assignment is a deck that succinctly communicates the Vision phase of our project. The goal is to use our research and activities from the Vision phase to develop clear, actionable insights and design pillars. 

Vision Activites.001

You can read my entire deck for the University of Texas system here. Now that this brief is complete, we’ll continue with the path we suggested to develop a Design Presentation that shows completed work. 

Key Takeaways

This approach was new to me. In the past, we’ve approached insight presentation as a story — delicately weaving the stories of our users into our narrative. By pairing down and focusing on the design pillars, I was able to think more about how our insights can– and should– lead to actionable design pillars.

This blog post from Matthew Strom was an excellent resource as I developed design principles for this project. The rule of “Good design principles aren’t truisms” was particularly insightful and forced me to hone in on actionable, potentially provocative design pillars that could guide a project. Rather than saying, “We should support students” (obviously), I opted for “Focus on incremental growth” which is clearer. 


Supporting Sex Workers: Poppy Firestarter Launch

poppy logo- transparent 150px

This is part six in a series detailing updates to our research which is grounded in the goal of supporting the safety and agency of sex workers. 

Design Team: Brittany SgaliardichLeah DiVito


Screen Shot 2020-02-22 at 9.20.18 AM


Poppy is a digital platform for sex workers to connect with each other, ask questions, and share stories, without censorship or stigma. The goal of this product is to create a communal space where women can share knowledge and build community on their terms.

For this phase of our project, we attempted to validate that a platform like Poppy is something that women in the industry are interested in using. While we plan to build something entirely new, our initial testing uses the private messaging platform, Slack. Access to our Slack channel is invite-only.

Summary – what we did

    • Service blueprint. We drafted a service blueprint of the Poppy platform that focuses on our initial pilot experience. This blueprint examines the touchpoints a user will have with Poppy and the interactions, both physical and digital, that support them. As part of this effort, we also created a content calendar to identify a schedule around discussion topics and facilitation strategies. 
    • Initial prototype. Using Slack, we finalized our initial prototype. We walked users through the steps required to create accounts, join channels, and respond to initial discussion prompts. We also create a poll to determine what discussion topics users were most interested in.
    • Landing page. We redesigned our landing page to more strongly correlate to the brand identity we are trying to create. This page will serve as an initial touchpoint in joining our Slack channel.
  • Firestarter. The Poppy firestarter served as a kickoff event for getting a core group of users onto the Slack platform. For this to happen, we created an agenda, sent informational emails, and implemented the launch. We ultimately accomplished the following:
    • Six invites, six sign-ups, two Firestarter attendees and began co-creating community guidelines
    • Discussed most valuable future channels
    • Provided next steps for users
  • Legal counsel. This project requires a close relationship with legal counsel. As part of this effort, we met with a lawyer who shared valuable insights but could not offer advice in writing. We also followed up with additional leads:
    • Through a friend, we contacted the Walters Law Group, a law firm that addresses issues related to the adult industry and sex workers.
    • Our studio instructor, Jonathan Lewis, connected us to Dr. Henderson, the Professor and Chair Department of Communication at Trinity University. We plan to chat with her on Tuesday.
    • We attended a networking event for national legal resources and received guidance for moving forward.
  • New users. We continued sourcing potential users. 
    • Strip clubs in Austin. We discussed our project goals with strip club management for entry into the club. While there, we approached women one-on-one to pitch Poppy and collect emails and invite to Poppy. 
    • Existing relationships. We also continued to tap into our existing relationships by encouraging women we have previously spoken with to invite friends and peers onto the platform.
    • Candy Girl podcast. We met with the creators of Candy Girl podcast, a show that explores the sex industry through interviews with sex workers in college. We plan to share our research and connect with women in the industry who are interested in co-creating with us. 

The challenge.

This week, our most important task was to launch the Poppy prototype through a firestarter or kickoff event. The challenge continues to lie in the legal constraints of our topic space and the acquisition of legal counsel necessary to responsibly launch the prototype and manage user experience.

The insights.

What new knowledge did we create this week?

  • We need to get legal advice in writing.

In order to create terms of service for Poppy, we will need consistent legal counsel to ensure that we are responsible creators of this platform. We must retain legal advice in writing in order to sufficiently protect both ourselves and our users.

  • How can we begin to promote active engagement outside of planned events?

While our kickoff event was successful, our team must continue to drive engagement onto Poppy. This effort will hopefully lead to self-sustaining growth and organic engagement. While we will continue to expand the platform and seek new users, we must simultaneously figure out how to facilitate discussion among users in a way that feels both natural and delightful. 

  • We must learn to vet users as quickly as we gain them.

As we continue to identify legal obstacles, we also realize the need to establish a reliable way for vetting new users that parallels the pace with which we acquire them. This will enable Poppy to grow with control, safety, and an informed strategy.

  • How can we screen users at scale?

We realize the need to address platform scale even now, in its infancy. We must be asking what it looks like to vet new users as our existing user ecosystem grows. The risk of a user-screening process, especially at scale, could be significant if not done in the right way. We want to make sure we focus on the safety and exclusivity of our users while creating a delightful experience with the platform – and these goals can feel at odds.

  • Flexible blueprint

As soon as we began building our blueprint, we realized that the future of our social platform requires a degree of flexibility that is difficult to predict. Given that this tool should evolve organically, we want to iterate on the blueprint as we work through new versions of the prototype and receive feedback from users.

Next steps.

  • Continue to seek new user base.
  • Continue to facilitate user events to continue co-creating the platform.
  • Continue pursuing existing and potential connections with legal help.
  • Develop and test vetting techniques for new users.
  • Create higher fidelity wireframes of “blue sky” platform to vet with current users.

Building To Bambu

This is the 6th edition of updates to our capstone project based on research Ana and I conducted with low income families in quarter two at AC4D. You can get up to speed last week’s post.


This week Ana and I first established a two by two grid to check out the existent product landscape. Through this exercise we were able to see how To Bambu differentiated from existent services. Our value proposition is we’re not only designed to declutter closets, but help families in need by providing them equitable access to children’s goods. Through illustrating a few products, establishing a loose set of inventory and investigating payment structures we were better able to fill in the blanks on our service.

(Our two by two of the current children’s resale landscape.)



Our website displays the basic skeleton of what we hope to achieve with vignettes. A donor/user page to better explain how our service works. We will provide insight as to why To Bambu is a better choice than competitors, and a choice of items to view. We’re midst set-up and are trying to curate a flow for both end users and donors. We’ve been researching how other sites are doing it right or wrong. Having to shift between customer and donor mindset is important in understanding how our website will work best.

We are considering each part, from families wanting to get rid of goods to the last email the buyers will get after completing a purchase, this service has to have proof of trust in every part of the process. During this process we also found out that there are several things parents don’t feel comfortable buying second hand, we will need to establish a list of do’s and don’ts on the website. Rules of what we will accept and what we will not because of hygiene, safety and many other variables. We will also need to do a list of things that must be in a product, for example; seatbelts in strollers, clean toys, cribs and strollers from after 2015 when the most recent safety standard for strollers became mandatory. All of these research insights have been very eye opening when thinking about our inspection and quality process.

(Our service blueprint for To Bambu) to better understand all the parts and players of our service at this point in time.

Screen Shot 2020-02-21 at 6.37.47 PM

Things Learned

To Bambu is specifically designed to not only declutter family closets, but it also helps those that need it the most by providing access to quality goods at attainable price points. We spoke with a classmate about how she went about setting up her business. She spoke of the in’s and out’s of LLC’s sole proprietorship, and the like. (Thank you Michelle). We also spoke with a school owner about difficulties they encountered when establishing their business, and holding money from deposits online. Lastly we discovered parents really are looking to get rid of stuff. We have a few potential donors ready to give us their children’s goods. (Some of which still have tags on.)

Progress and Prospects

We made great progress on understanding the scope of our service. Whether To Bambu serves as a portfolio piece, or a viable business, getting our hands dirty is proving to be invaluable. As we continue to define our product and revisit how we can serve people we’ll  continue to share with those willing to listen.

In the final week of studio we hope to develop a logo, polish our website interface, post inventory, establish user and donor flows and start prototyping.



Prototyping Vouch

This is the sixth installment of our team’s (Allison, Laura, Michelle) project for our Studio and Ideation class. This project builds on the research we did with gig economy workers last Fall, which you can read about here and here.

After feedback from last week, we decided to dedicate ourselves fully to Vouch, a service that makes it simple for friends and family to lend money and build trust. In Vouch’s current state, it’s primarily used as a simple method to get both lenders and borrowers on the same page. We heard in our research that loans between friends and family are often messy when terms are not decided upfront. 

With Vouch, both borrowers and lenders can quickly fill out a form to determine the loan amount, interest rate, payback schedule, and any other options like equity or collateral. Vouch serves as a point of truth. One of our main design principles is for Vouch to inform and foster connection, but not mediate. 

Our primary goal for this week is to bring the idea to life as an MVP and validate whether this concept has legs to take us into Q4. 


Our progress this week

Built out our website including a landing page and two pages.

  • We revisited our value props and focused on transparent terms, simple reminders, and shared loan tracking. You can see the entire website here:


Created forms to serve as our customer intake. 

    • Created a diagram of the user types that our product can serve to think through on-boarding flows.Screen Shot 2020-02-21 at 7.30.49 PM
    • Using Typeform, we created conversational forms that allow both borrowers and lenders to easily disclose the terms of the loan. This is our on-boarding mechanism for Vouch users.
    • See for yourself: Form for Borrowers, Form for Lenders
    • We hypothesize that borrowers will be our primary audience, but we wanted to build out both flows and test to validate that assumption. 


Drafted a System Diagram to show user touchpoints. 

      • Our system diagram quickly shows how little the user has to do. One of our goals was to keep things clear and simple for users. 


Built out our communications flow, copy and visual assets.

    • Terms editing, reminders, and payment confirmation all happen through text or email, so we drafted responses for our eight possible flows. 
    • Read our copy
    • We also created visualizations of the repayment process that can be included in communication with borrowers and lenders.
    • vouch-data1 vouch-data2


Posted to Craigslist and other forums to find customers.


Reached out to friends and family to recruit customers.  

Insights & Feedback

We did a few talk aloud exercises as users walked through the lender forms for new and existing loans. The purpose of the talk aloud was to capture immediate, instinctive feedback. We asked questions about what felt good and clear, what gave pause or hesitation, whether they saw value in the service, and whether they would recommend the service to someone else. 


What do you like about the service? 

  • “I like the idea that you take the anguish part of it out of the lender. Vouch would be cushioning the blow.” 
  • “What I really, really like about this app is that you’ll do the reminding. Because I’ll either be ignored or hear excuses.”
  • “It shows me I got to be stricter about my expectations. Because I don’t set up any expectations, I don’t set up any plans.”
  • “Neat, clean, clear, simple. I like that it’s not a whole lot of information. Or too glitzy or whatever.”
  • “Getting this to college students who I would think, off and on, would be borrowing money – ‘Okay Mom and Dad I found this thing called Vouch – let’s do it this way.’ Working from the opposite end to attract boomers to it. Having the borrower approach shows initiative, responsibility.”


Would you recommend this service to anyone else? 

  • “My friends – we don’t talk about money that we loan to our kids. Usually it’s a very private thing between people… It would be so rare that I would tell anybody about it.” 
  • “I think it lays it out clearly – the things that could be discussed – to protect everybody and to keep on good terms so that both of you are on the same page with the borrowing and the lending. Not everyone wants to borrow money but this must make it more comfortable for them knowing there are standards and expectations that are clear.”


Notes on language

  • “Being on the same page is a manner of speech that we understand, but is a colloquialism that is culturally specific.”
  • What’s the name of the person – kind of casual. Maybe that’s on purpose to be friendly but in all my professional writing I’ve never used contraction. I thought oh, maybe this isn’t so professional. That flashed in my mind.”


We received feedback that the terms could include more room to articulate the flexibility and understanding that often exists with this type of loan. 

  • “If you miss a payment, how would that work? How would it know if you didn’t pay me for a couple months or I knew you were in dire straits?” 
  • “I can’t just look at things as cut and dry. I look at situations.”
  • “Repayment to family gets put behind things that are more important – it’s easy to get pushed aside because we’d be understanding.”


There was a suggestion for a pause and resume option, affording the borrower time to get back on track. Flexibility and understanding is partly why we borrow among friends and family. Due to the intimate nature of these loans, folks are often well aware of the situation or struggle a borrower may be in – highlighting that help extends well beyond the cash assistance. How can we adequately represent this moving forward? 

Next Steps

For our last week of Q3, we want to edit our sales deck to be a really tight, succinct pitch for Vouch. We’d also like to gain real users (not just friends and family) and hopefully — get a few success stories. Lastly, because our goal is to get borrowers and lenders on the same page, we want to design a terms sheet that is simple, straightforward, and easy to understand. User feedback will help us iterate on how best to visually represent the terms so we’re eager to get this in play.