• October 10, 2015

the VENTUREAPP product

the VENTUREAPP product

Saturday, 10/10/2015

Hey VTQ sa-vajes,

Here’s the latest breakdown of functionality, user experiences, and Houston implications for what we’re building. We’ll be deploying this on Fri, 10/23. Please review the following strictly with regards to flow and functionality and and drop feedback for anything you think, feel or question in the public GDoc. We’ll get nit-picky with UI elements, branded copy and email touch-points when all functionality is built.

Since it’s integral to the rest of the platform, we’ll start by explaining what new info we’re asking when users submit a new Request…

More Info on Requests:

Additional data on Requests is beneficial for mainly two reasons: 1) it helps us find the right solution for our users and 2) it helps us scale the network to de-risk operational overhead. Here are the data points we’ll ask for when someone submits a Request:

  1. Type: Product/Service, Introduction, Advice, Reference. (screengrab first step of New Request)
    1. users can request a product/service. Ex: “Need a better CRM.”
    2. users can request an introduction to someone. Ex: “Need an intro to BostonSeed.”
    3. users can simply request advice. Ex: “Need help organizing my sales team.”
    4. users can ask for a reference on an individual or a company. Ex: “Need a reference for John Doe.”
  2. Category: Marketing, Real Estate, Legal, etc… (screengrab second step of New Request)
    1. users can set one category (a primary tag in our database).
    2. this is a baby step into (potentially) the most scalable data point for Requests.
  3. Anonymous: Keep anonymous or make public:
    1. default is anonymous.
    2. all Requests via email are set to “anonymous” automatically.

If a Request is anonymous or public influences its homepage appearance and functionality. We’ll start with homepage…

The Homepage:

The homepage is our network page. See the best Requests and the most recent Requests.

The homepage will have at least 2 tabs: Recent and Featured. We’re still unsure which one should be the default.

  1. Recent Activity: a feed of the most recent Requests made into VENTUREAPP.
    1. the Request has to be assigned to an admin before it appears on this page. Obviously, we can change this, but this seems safest for now.
    2. VA staff can set a “homepage subject” and “homepage body” on each Request (in-case the Request’s original subject and body has private info).
    3. VA staff can remove a Request from the Recent page.
  2. Featured: staff-selected Requests
    1. staff will be able to mark any Request as “Featured” and be able to order it on the “Featured” Requests page.
  3. Popular: a feed of our current popular Requests

Here’s what an anonymous Request looks like (notice that the company’s headcount, industry and location are public):

Here’s what a public Request looks like:

Viewing a Request:

When a user clicks a Request from the homepage, he or she will see the above. Notice the three features: Reply, Refer and Clone.

  1. Reply: the ability for anyone to communicate with the Requester. (screenshot)
    1. if the Request is anonymous, the Requester’s name and company are hidden unless they respond.
    2. once a Reply is submitted, the Requester receives a “UserX replied to your Request” email.
    3. the Replied also receives an email: “You just replied, here’s what happens next”
  2. Refer: the ability for anyone to send an invite email. (screenshot)
    1. for example, if I see a commercial real estate Request on VENTUREAPP and I know a broker, I can invite him to Reply to this Request.
    2. This acquisition mechanism is probably one of our most valuable, since it helps define a business network.
  3. Clone: the ability for anyone to submit this Request for themselves.

My Profile:

The Profile page is where a user can manage their Requests and Replies. When a user clicks on one of their Requests, they see the page below (or here).

  1. On the left, there are the conversations they are having with VENTUREAPP as well as anyone who has replied to their Request.
  2. Again, the Requester’s information won’t be presented to the Replier.
  3. Users can invite teammates and/or anyone else to a conversation.

For every Request, the first item in the left-hand nav will be the Requester’s conversation with VENTUREAPP. Additional Replies will follow chronologically on the left.

Houston Implications:

Here’s the current flow for responding to a Request in Houston:

  1. Request comes in
  2. VENTUREAPP responds, qualifies
  3. VENTUREAPP loops in a solution provider into the request.

In the new flow:

  1. Request comes in
  2. VENTUREAPP responds, qualifies
  3. VENTUREAPP creates a new Reply and intro’s the Requester and a solution provider.

This will help isolate conversations between multiple solution providers and Requesters.

Wrapping up

There’s a lot in here, so thanks for reading. For more additional information, please consult your local developer at dev@ventureapp.com.

Check out all mocks. Throw feedback in this public GDoc.