Remember Office Hours in University? If you don’t, it was a time that professors just left open in their calendars and students could book some time during those blocks to come and have a chat. As a student, you usually went to the office hours for the classes you cared about most, or maybe the class where you were really struggling but wanted to do well. It was part brainstorm, part catch-up, part therapy. It was a chance to clear your head and perhaps it kept you out of the weeds for a few weeks after. Sometimes it was the only time you got to talk about a paper or a project that you’d worked on for weeks or months.

Building products, as an entrepreneur or a product manager, can sometimes feel a lot like being a perpetual student. You are always faced with new information coming at you, you have to synthesize it, make decisions and make the idea your own. A lot of the time you’re going at it alone or with a very small team, and you often feel pretty isolated. What do you do when challenges come up, like when sign-ups drop, or your growth levels out? Who do you talk to?

Pivots have met a ton of CEOs and Product Managers at meet-ups and conferences who are working on great ideas and have really promising products. We shoot the breeze, take a look at their products, offer ideas, and help them focus on the possible solutions. The appreciation we receive often seems disproportionate to what we think we offer until it came clear how valuable collaboration and community is when you feel as though you’re doing it alone. So we formalized the process and rolled out Pivotal Labs Product Office Hours. This program of lunches, where Pivotal Product Managers and Designers meet with people who are building things and chat about the challenges they face, went live in NYC and San Francisco last year. We are really psyched that we are now bringing it to our London office in Autumn 2014.

So what’s the deal, really (I hear you ask)? The deal is that you send us an email to office-hours@pivotal.io, tell us a bit about yourself and your product (Make sure you mention you’re in London.) Someone will be in touch to schedule our lunch and maybe ask some clarification questions. Then you come down to our Old Street office on a Friday from 1230-130pm, eat some free lunch and a few Pivotal Product Managers and Designers offer you no-holds-barred advice on how to tackle your most pressing product issues. Can you come in again in a few weeks to let us know how things are going? YES, please do. The lunch is free, the advice is free, the bus fare over costs £1.45. There’s really no reason not to sign-up and come in.

So what’s in it for Pivotal Labs? Well, we get to meet awesome people who are doing cool things. We get to exercise our critique muscles and we get to have cool conversations. If you want some more specifics, you can check out these blogs about WeeSpring and Notable and how to frame your problem, to get an idea of how these sessions go. There is no general template, each session evolves in response to the product discussion at hand.

In this blog post we describe a process to replace a VMware vCenter Server Appliance’s (VCSA’s) self-signed certificate with Certificate Authority-signed (CA-signed) certificate.

VMware has already described such a process in Knowledge Base Article 2057223; however, the process they describe is cumbersome: it requires SSL certificates for four services that the VCSA provides.

vCenter Server / vCenter Single Sign-On (SSO)

vCenter Inventory Service

VMware Log Browser

vSphere AutoDeploy

We are not interested in replacing the SSL certs for all four services—we are only interested in the replacing the certificate that our web browser encounters we browse to the vCenter (i.e. the vCenter Server / vCenter Single Sign-On (SSO) certificate).

Also, we do not have four CA-signed certificates to install; we have but one wildcard certificate (*.cf.nono.com) available.

This Voids the Warranty!

Following this procedure will result in an unsupported configuration! Wildcard certificates are not supported according to the Knowledge Base article:

“The use of wildcard certificates are not supported with vCenter Server and its related services. Each service must have its own unique certificate”

We feel comfortable in replacing one of the certs with a wildcard certificate in spite of VMware’s prohibition, for we are still maintaining four different certificates for the different services (though one of the services will be using a wildcard certificate).

Problem Description

In Cloud Foundry Engineering the Chrome Web Browser is the most popular browser among the developers, but it is not without shortcomings, especially with regard to self-signed certs.

Google’s Chrome web browser under OS X has difficulty permanently storing exceptions for websites which have self-signed certificates (a complicated work-around would be to visit the site in Safari and store the exception in the System’s keychain). Every time Chrome is restarted and the site with the self-signed cert is visited, the user encounters a warning screen. To make matters worse, a recent Chrome update requires the user to click not once but twice to get past the warning screen.

Chrome’s warning screen when encountering a self-signed certificate. This is particularly irritating under the OS X environment, for Chrome does not have a built-in mechanism to store certificate exceptions

A fix would be to use CA-issued certificates for frequently visited internal servers. It’s trivial to install certificates on most servers, but the vCenter Server Appliance is a more complex install.

Every Wednesday, Pivotal Labs Product Managers gather over lunch. Sometimes we discuss a book we have been reading. Other times we discuss a particular client’s product and offer feedback. Recently we have been trying a bit of an experiment: we critique products on Product Hunt. Informally, we have started to refer to these exercises as “product hunts.” For 60 minutes, we dissect the product, business model, and technology, and throw our thoughts on a mural to post here.

This week’s product hunt was special because we selected from this years TechCrunch Disrupt finalists, ultimately critiquing the winner of the competition, Alfred. Alfred is the “first human powered operating system for your life.”

We also had the privilege of our PM friends at Yammer, Ankit, Philip, and Laurence, joining pivots Rhea, Kirk, Shuqiao, and myself for the Alfred product hunt.

We shared 40 hours a week, a screen, a product, client relations and a problem space. Now we’re on a quest to codify the tenets of pair design.

Pair Design Rule # 3: Accept your pair’s exotic habits.

We designers are an interesting bunch. Snowflakes. Unicorns. Butterflies. Rock Stars. Special. We. Are. Special. Our habits are also special and good and make us individuals which in turn makes us creative, critical and exploratory. In all of this, we can develop little quirks of personality that surface when design pairing.

Rather than fix, just accept. We all have our own odd extra ears and whatnot. Embrace it. Grow your own practice by fully understanding the motivations that drive your design buddy to do all the crazy things that make you want to nibble on glass.

Habits We Have Found in the Wilds of Pivotal Labs

Layer Lover They love layers for all things. Nav. Hand interactions. Their 147 layers are very organized.

Layer Hater They hate layers for all things and “fix” all layered files to have no layers.

Data Hoarder Copying and pasting ten versions of the same screen into one document, so that nothing is lost. Ever. Really. Ever. Saving a new version of the same file every 20 minutes, to enshrine the “process”. It’s meticulous version control, so that later they can reflect on process, inspect the deltas. That day may or may not come, but they’ll be ready for it.

Neat Nuts Accidentally cleaning up an entire Dropbox folder in trash because they were “neatening.”

Symbol Worshiper Symbols all the time. Always making a symbol in Illustrator because it’s “more efficient” even if they have no idea what the page will look like.

Fancy Pants Coder Writing all notes, everything in markdown

Font Optimizer Loyally using fonts from Typekit only.

Recovering Architect. Writing every single note or whiteboard scrawl in small caps.

Key Commander Using or creating custom shortcuts for everything.

Mouse Lover Never creating shortcuts. Imma just gonna take my hand and put my whole consciousness in this curser here. It’s called a mouse!

Chatty McStarter Oh, they want to talk… They need half and hour of banter before the worky work starts.

Cheer Captain Very enthusiastic team “yays!” and positive reinforcement sprouts like flowers in their path.

The no breaker The Olympic athletes of the design world, they haven’t taken a break since 2007.

Armchair Psychologist Standing on one leg at meetings “to make them go faster and be healthy.”

Coffee Pot Worshiper The first half an hour of each day happens next to the coffee machine, in a complex dance of beans, cream and project planning.

Email Multi Tasker They are with you… until gmail calls their soul home.

Remember, our greatest strengths are often our greatest weaknesses. So be kind and patient with your design pairs. If you are working with someone, it is because they are talented. Their habits are actions that spur from what they value. If you can figure out what they value, and you can learn about their practice, and in turn grow your own practice. Nobody said it was easy, dangit.

Background

About the Retailers

With their high revenues and established market presence, the top 10 U.K. mCommerce retailers (based on Internet Retailer’s Top 500 Mobile Guide) certainly have the resources to build stellar apps that drive revenue, brand awareness, and customer loyalty. So why are some still falling behind, launching poorly executed products that tarnish the brand image and turn customers to competitors?

What the 2014 Retail Apps Report Covers

We investigate these issues and more in the report. Our 2014 report delves into the features that are critical to success and assesses whether U.K. retailers are meeting the needs of their mobile users. More areas of coverage include:

Which retail apps rate highest and lowest

How to optimize performance of a retail app

Why great design is critical to keeping users

Download the 2014 U.K. Retail Apps Report

Download our exclusive 2014 U.K. Retail Apps Report to understand what retail apps are leading, what makes them successful, and why mobile is an opportunity for all retailers to boost engagement and drive the bottom line.

Here at Pivotal, we know pair programming is great. We strive to pair 100% of the time.

Sometimes, a pair might want to work on something complicated by getting in the zone together – to listen to music while pair programming. (It’s best when your pair shares the same taste in music as you!)

Other times, a pair may need to answer a call from a remote pivot or client. They typically will want to do these things while also avoiding disturbance to the team and the rest of the people on the floor.

Still other times, one pair might have trouble hearing with the background noise on the floor, and want to use headphones to amplify their pair’s voice above the noise.

If you’re an aircraft pilot – or you’ve been in an aircraft with someone who is – you’ll have seen how well a plane’s headset system works:

– The pilot and co-pilot have microphones that send audio to each other’s headphones, so they can talk to each other at any time.
– There is a “transmit” button, which causes what both people say to be transmitted by the plane’s communications system on whatever channel is active.
– The pilot and co-pilot both hear the plane’s communications system through their headsets.

This walkthrough will set up something similar in software, which will let you and your pair wear USB headphones, adjust your volume individually, and both “transmit” to people you work remotely with. This setup is something you won’t know you need until you try it!

Stage 1 – talk to each other through your headsets

Following these steps will route the audio from one microphone to the other headset, and vice versa.

1. Plug in both pairs of headphones. We use Logitech G35 USB headphones for their great sound quality and convenient microphone mute button.
2. Download LineIn from Rogue Amoeba’s freebies page.
3. Extract LineIn and option-drag it to create a second copy. The copy will be called “LineIn 2″.

4. Open both copies of LineIn. Arrange them so they’re not on top of one another. Configure one LineIn to send audio from one left pair of headphones to the other, and configure the other LineIn to send audio the opposite direction.

5. Click “Pass Thru” on both instances of LineIn to start your headphone pairing setup.
6. You should now hear each other while wearing your headphones, which cancels out some of the noise on the floor.

This lets you block out background noise and deal with any hearing problems.

Stage 2 – music in the background

1. Open “Audio MIDI Setup” (via Spotlight with Command-Space).
2. Click the “+” icon at the bottom left and select “Create multi-output device”.

3. Select your new multi-output device on the left hand side.
4. On the right hand side, ensure only your two pairs of headphones have checkmarks next to them.
5. Right-click the multi-output device and choose “Use this device for sound output”.

6. Optionally, right-click the multi-output device again and choose “Play alerts and sound effects through this device”.
7. Open iTunes or your music playing program and make sure it is configured to output audio to the default system device.
8. Adjust the volume so it doesn’t drown you out, and enjoy your music.
9. If you find your pair is quieter or louder than you and want to change the mic volume, select the headphones you want to adjust. The “M” slider on the “Input” tab controls your microphone volume.
10. You’ll also notice the multi-output device does not let you adjust the volume the normal Mac way. If you want like your volume louder than your pair, adjust the “1” and “2” sliders on the “Output” tab for your headphones.

Great, now you and your pair can zone out.

Stage 3: Pair on remote calls

At Pivotal Labs we like to help clients and developers in other offices by joining remote calls. Pivots may use Screenhero to remote pair with them, or may join a Hangout or Skype call. The cross-headphone music setup forms a foundation for remote calling between pairs. In stage 3, you will combine both microphones.

(Side note: you may have read about an “aggregate device”. We don’t use the aggregate device because the two microphones become 2 separate input channels. Applications that use microphones assume a single input channel. So your remote person will only hear one microphone.)

1. Download and install Soundflower – we won’t be using its user interface, so you can Quit the icon in the menu bar.
2. Open “Audio MIDI Settings” again, right click “Soundflower (2CH)” and select “Use this device for sound input”.

3. Where you made 2 copies of LineIn in stage 1, option-drag again to make “LineIn 3″ and “LineIn 4″.

4. Open your third and fourth instance of LineIn and arrange the windows so they are not on top of one another. Use both instances of LineIn to send audio from each pair of headphones to “Soundflower (2CH)”. Click “Pass Thru” on both to start them sending audio.

5. Ensure your application – eg. Screenhero or Google Hangouts – is configured to use the default system device for both input and output. Note that Chrome doesn’t allow microphone access in Incognito mode.
6. You’re done – go make your remote call.
These instructions should only take a few minutes – it is worthwhile to invest time in an ideal setup because you typically work with remote people for an hour or more.

But be careful: developers wearing headphones can be detrimental in the long run so consult your anchor and PM to decide whether this suits your team and project.

If you need help ask in the comments. Enjoy your new headphone pairing setup!

PWS is Pivotal’s public Platform-as-a-Service offering. PaaS systems let you host apps by pushing them to a service rather than having to configure and maintain separate installations of web servers, load balancers and so on. PWS is a hosted installation of the open-source Cloud Foundry project, to which Pivotal is a primary contributor.

You may be familiar with Heroku, one of the first cloud application platforms. PWS (or ‘p-dubz’, as it’s affectionately known at Pivotal) occupies the same space as Heroku, and as such is a competitor.

Although earlier in its development than Heroku, PWS is a very stable, viable alternative. It has several advantages over Heroku, but also has a few disadvantages, which the team are working hard to eradicate in the near future.

A decoupled CLI

Because it’s a Cloud Foundry installation, the PWS command line interface isn’t coupled to a version control system, as Heroku’s is to Git. I could, for example, start a quick project without version control and have it publicly available on the web using PWS in a few minutes.

This is a big advantage for teams using other version control systems. It’s also great for trying things out without committing them to version control. I shouldn’t have to change history in order to tidy up some commits that were only created to test the waters of my cloud platform.

It’s cost-effective

PWS charges by memory used by apps over time, and per month for any services used in the marketplace. You can try the system out for free for 60 days, after which apps are pay-as-you-go.

One advantage PWS has over Heroku in this area is that you can determine exactly how much memory to allocate, and therefore pay, for a given app. Whereas Heroku requires its users to allocate chunks of 512MB, on PWS I could choose to allocate 5309 megabytes to my app if I so wished.

Services like MySQL and PostgreSQL are currently charged up-front for each month, so don’t go deleting and recreating them with abandon, to avoid surprises in your monthly bill.

Great support

We have a dedicated Cloud Ops team who maintain the system, so you don’t have to be up in the middle of the night when a server gets upset. In addition, we have a highly knowledgeable support team, known to get customers out of pickles entirely unrelated to PWS. There’s also an active forum.

The future: one-off tasks

One-off tasks such as database migrations on PWS aren’t quite as slick as you may be used to on services like Heroku. Whereas on Heroku you can:

heroku run rake db:migrate

On PWS the traditional workaround for a lack of support for one-off tasks is to run migrations on one instance as part of the app’s startup command. Details of this and other techniques are on the Cloud Foundry database migrations documentation.

The future: more services

Heroku boasts many more add-ons than PWS. If you can’t wait for more vendors to join, however, you can easily create your own service that bridges the gap between any SaaS provider and PWS.

Getting started

If you’re on the lookout for an easier, cheaper, or more compatible way to deploy and maintain your apps, signing up for PWS is painless. It’s also a skill worth acquiring: as more companies adopt Cloud Foundry as their platform of choice, your experience with PWS will stand you in good stead for pushing apps to those internal platforms.

If you have any questions about the service, feel free to add a comment to this post.

What was the worst thing that a startup could do when working with her?

Fran thought about it for a second, and replied:

Not follow-up.

She went on to talk about how if someone is supposed to send her something after they meet, that forgetting to is not going to help build the relationship. Fran added that sometimes people spend so much time making sure the deliverable is perfect and end up missing their opportunity to stay front of mind.

A great follow-up can set you apart, especially if it’s timely.

I remember, when I was a Cornerstone on Demand, that one of our PM candidates found a way to have hand written thank you notes delivered to each person who had interviewed her… THE VERY NEXT MORNING! We hired her for a variety of reasons, but that was something each of us remembered for years.

Follow-ups are a great way to continue a conversation and stay relevant.

Camp Interactive, which visited Pivotal Labs a month or so ago before they spent a week building apps, sent me the most adorable thank you note today.

Here’s what I love about it:

It has great photos of the students learning and having fun during their week at camp.

It was hand written by one of the participants who wrote why she personallyenjoyed visiting.

It was in addition to the emails I had already received immediately after their visit, so it wasn’t delayed but more of a “we’re still thinking about you” reminder.

Things like this make me want to help Camp Interactive out in the future, and may have encouraged one of my coworkers to run a marathon for them. Now that’s an impactful follow-up.

You may know Pivotal for their great enterprise offerings and the Pivotal tracker. Did you know they have an amazing product team as well? After connecting with PivotalLabs, Serge and I attended an “Office Hours” session a few weeks ago to learn more.

Pivotal’s Office Hours for Product is new. Every week they invite startups for a free lunch with a side of product grilling (a community service!). They get in touch beforehand to get a sense of how they can help, then spend Friday lunch brainstorming. In our case we knew (then and now) that our first “user experience” of Knotable needed a thorough shake-up.

We met Tami, Jeana and Lauren in the lobby of Pivotal’s awesome Chelsea offices. Then got straight to the main event; lunch. I picked a scrumptious mediterranean blue cheese salad. Serge had a Californian affair.

We went to a meeting room and got down to the (actual) main event. Lauren did the honors of going through a “first user experience” of Knotable, monologuing her impressions (in impressive detail) as she went. Tami and Jeana took notes and added commentary. Serge and I scrawled furiously and tried to keep as quiet as possible to avoid bias.

Once Lauren was done, we put our heads together. Tami took charge by organizing everyone’s comments into a collage of sticky notes on the whiteboard. We broke them up into roughly five categories: On-boarding Issues, Usability, Inconsistent Design, Unclear Messaging, and Expected Behavior.

That’s when things got real. We all chipped in like front row kids in school, trying to get our observations and insights on the board. There were no holds barred by the Pivotal team. Their comments were incisive and on point. Some of their feedback was familiar, but much of it was novel and illuminating. Having three fresh sets of trained eyes on our product was productive.

No sooner had we started, then it was all over. We packed up the stickies from the board, cleaned up our plates and said our farewells. Tami mentioned that teams often found it useful to return after about a month to review their progress and invited us to do the same.

We both found the experience helpful. Anyone looking to get an honest bit of constructive criticism from some of the best product people around should get in touch with Tami to set up your own free lunch.

Based in Dallas, Savoya is currently building out their tech team from the ground up with the help of Pivotal Labs.

This is a great opportunity to join a thriving company. If you’re interested in the position please reach out to the savoya team here: careers@savoya.com

ESSENTIAL DUTIES AND RESPONSIBILITIES:

We are looking for a team of two developers located in Dallas, TX to work in conjunction with Pivotal Labs to create our next generation internal and external software platform. Become founders on our new development team – set the culture and build something excellent from the ground up. Create an exceptional, custom-built global chauffeur logistics management solution for the most discerning global travelers. Responsibilities include interpreting requirements to identify and evaluate solution alternatives, developing and deploying high-quality applications. You will be part of a team that prides itself on its ability to continuously release reliable, scalable, high-performance technology solutions using modern design and development patterns. You will be an integral part of a strong, tightly-knit, collaborative development team working with a product owner and other key internal stakeholders.

JOB REQUIREMENTS:

Proven experience in development of flexible and scalable web-based applications

Passion for technology, specifically software development

1+ years of experience with Ruby language and the Rails framework, be proficient with the entire Ruby on Rails stack

Proficiency with relational databases, including design and development
Working knowledge in development of MVC-based web solutions

Ability and desire to thrive in an Extreme Programming environment, including pair programming

Competency managing source control and automated build processes

Excellent analytical and problem solving skills

Strong communication and interpersonal skills – eager to dialogue directly with process owners and system users

SAVOYA OVERVIEW:

Our team delivers perfectly executed ground transportation in 60 countries worldwide. Our clients are meeting planners, flight schedulers, executive assistants and travel planners who expect the highest levels of responsiveness and reliability. Since 2000, we’ve been redefining customer service and delighting clients with a stress-free ground transportation experience. When it has to go right, trust Savoya.

DESIRED EXPERIENCE:

Experience with agile software development methodologies such as SCRUM and/or XP

Working knowledge of test-driven development and related frameworks (i.e. Jasmine, RSpec)

What’s the hardest thing about becoming a new mom? According to Ally Downey, it was knowing what to buy. “The first time I walked into a Babies R Us, I burst into tears,” she said. “I looked up at a ten-foot wall of baby bottles and saw — in all of those options — a metaphor for how completely unprepared I was for the hundreds (thousands!) of choices I’d have to make for my baby.”

She turned to her friends for help and found they were eager to share what to buy and what to skip. “…[A]s my inbox flooded with advice from my in-the-trenches friends, I started to feel a little less overwhelmed and a little bit more ready. By the time my baby arrived, I’d become one of the ones sending the instructive emails (Get Triple Paste in the tub, not the tube!).”

She saw not only a tremendous pain point for parents, but a huge business opportunity, with new parents spending roughly $5,000 on baby products in year one alone. So soon after her first child was born, Ally launched weeSpring — a place for expecting parents to find reliable advice on what to buy, and for new parents to share what they had learned. A year and a half later, weeSpring is a vibrant community of new and expecting parents with over 150,000 product ratings. Expecting parents can log in via Facebook to see what their friends have reviewed, save products for later, and build lists like “Newborn Necessities,” “Teething Time, and “Best Gifts for a One-Year Old.” New parents can share their own tried-and-true advice and learn about new products as their baby grows.

User Acquisition Experiments

Like any growing startup, weeSpring has been experimenting with ways to reach new users. By writing a blog that details their favorite products and tips, building a strong Pinterest presence, and experimenting with paid advertising, they are seeking out the most effective channel to reach new and expecting parents that convert to registered users. As they sat down to analyze which experiments were converting the best, however, Ally and her co-founder Jack found a pattern they didn’t expect.

First time users were arriving at individual product pages deep within weeSpring via search (e.g. google) and referral (e.g. through a blog post, an email from their mailing list, or a Pinterest page)

First time users were overwhelmingly arriving on mobile devices

First time users who came to deep linked pages were not signing up at a comparable rate to first time users who landed on the the homepage

Front Door vs. Back Door User Acquisition

weeSpring had stumbled into a classic startup challenge: new users coming in through the “back door” (from search or referral) did not understand what weeSpring was and how it offered value. They were not signing up and they were not reviewing products. In short, they weren’t behaving the same as new users who came in through the “front door” (from weeSpring’s homepage, which has a strong onboarding flow).

weeSpring signed up for Product Office Hours to get some advice on what to do next. Product Office Hours is an hour of free consulting offered by Pivotal Labs for startups who want advice on how to move forward when confronting a particular challenge or feature.

Developing a Back Door Acquisition Strategy

We (the team at Pivotal Labs) helped weeSpring identify that they were ready to dedicate design and development resources to address the needs of their new back door users. We then led them through two activities to design an experiment to focus on converting back door users.

First, we determined the goals of a back door new user who had clicked onto a weeSpring product page (e.g. Aden and Anais swaddle blankets) from a blog post, a Pin, or a newsletter, but had not yet signed up. We concluded that back door users wanted to:

Learn more about the product (read a quick summary and see other photos)

Buy the product (redirects to Amazon)

Save the product

Learn what other parents think of the product

Second, we needed to figure out what had to be on the page so that a back door user could achieve his or her goals. We determined this in four steps:

List out existing calls to action. We wrote each call to action on a separate index card. We listed out nearly 20 separate prompts, such as “view Q&A,” “share on Facebook,” and “ask a question.”

Remove what is not relevant. Certain prompts, such as indicating that a user has a product or seeing what her friends think of it, are irrelevant to a user who has not yet signed up for an account.

Prioritize user goals. Focus on actions that are contextually relevant. For weeSpring, this meant prioritizing calls to action that matched a new user’s intents, such as buying and saving a product.

Don’t forget conversion. When is the right time to ask a user to create an account? After the new user understands what they are looking at, why it is for them, and how it adds value. We all agreed that if a new user clicks “save this” on a product page in weeSpring, he or she “gets it” and should be prompted to create an account.

Ally and Jack walked out of Product Office Hours intending to roll out an experiment with the goal of improving conversion on logged out product pages for first-time mobile users.

Back Door Users Buy More

Several weeks later, they rolled out small changes to their logged out mobile page. Since the change, they are seeing two positive signals:

New users who arrive via the back door are now converting at a comparable rate to those that come in through the front door

New users that come in through the back door are 4x as likely to click buy as new users that come in the front door.

You can see the changes that the team made in the screenshot below, which compares a logged in (L) versus logged out (R) product page on mobile.

By making small, pointed design changes to focus on purchase, conversion, and communicating their value proposition, weeSpring has been able capture more new users to sign up and buy. They can now feel confident making bigger changes to product page because they have validated the basic concepts.

We’re looking forward to seeing their new product page, as well as new experiments to encourage back door users to complete front door activities (such as rate and review products).

We shared 40 hours a week, a screen, a product, client relations and a problem space. We raved about the joy and productivity of pairing is this post, and now we’re on a quest to codify the tenets of pair design.

Pair Design Rule #2: Yes, and!

Rather than bulldozing your pair with your own ideas, take their ideas and build on them. Don’t judge your pair’s idea and toss it away. It’s called “Yes, and…” It’s when you say yes, and to every idea and build on it, like paving a highway for discovery and exploration.

Yes, and! It works in improv. It works in marriage. It works in pairing. True story, just witness the brilliant ‘Yes, and’ demonstration by Janice and Jason on making breakfast a la ‘Yes, and’.

Breakfast of NO

“oh, I’m sorry, uh how about some tea, a bloody mary and a sea anemone, I hear they’re really good for muscle relief”

“I had a bloody mary last night, no sea anemone”

“uh, sure… *shutter*”

Which partnership would you rather be in? The first one I think.

Okay fine, breakfast is one thing, but how do you say ‘yes, and’ to Lobster, 12pt font paragraph styles, really?

Timebox it. Give yourself a limited time commitment of YES. One of two amazing things will happen:

You end up somewhere wonderfully unexpected, like deconstructed ice cream breakfast, whimsical logotype or a 21st century marauder’s map. Voila!

Or…. You will both be convinced of the sheer insanity of ice-cream breakfast, Harry Potter-inspired interfaces. But now you’ve explored, you learned, you went down the rabbit hole and back up to clear the space for new, fresh, sane ideas. It’s a wonderful journey of discovery, like Dr. Seuss meets Tim Burton for a hackday.

So start slow, say ‘yes, and’ to the next idea you hear, be it brilliant or Lobster. And tell us, what did you come up with? Where did ‘yes, and’ take you today?

So, you wanna deploy to Heroku… It’s super quick to get something up and running, but if you want a robust, production-ready system, you’ll have to do a bit more than just git push. Without further adieu here is my checklist for things to do when getting an app ready for its first production deploy to Heroku.

Add rails_12factor to your gemfile Rails 12 factor app will log to stdout so that heroku can see your application level logging. It also has your Rails server serve static assets since you don’t need something like Nginx to act as a reverse proxy/static file server when using Heroku.

Sign up for a log aggregation service In order to retain logs, you must sign up for a log aggregation service that Heroku will stream your logs to. Without a log aggregation service you will be able to tail logs on a live application, but you won’t be able to see them later. There are a number of logging services available as Heroku add-ons, such as Loggly and Papertrail.

Choose a robust application server. WEBrick, the default Rails server is only suitable for development. It can only serve one request at a time. There are a number of very good choices for an application server, Unicorn is great and is generally seen as the default choice these days. However, if you have slow clients you may consider either Puma, Rainbows or Thin.

Add performance monitoring. You’ll want a service like New Relic for general monitoring of things like up time, heavily used/slow queries, etc. It’s always useful to know how your app is behaving in the wild.

Add error reporting. Choose a service like Airbrake or Honeybadger so that you are notified when errors occur in your application.

Double check your database settings and plan. It’s always best to make sure that you signed up for the right tier of service from your database provider. For starters, check that you have a big enough database. It’s also prudent to make sure that your connection pool is set high enough, and that your plan supports enough concurrent connections for your set up.

Set up release tagging (and script your deploys). It’s vitally important to know exactly what code is running in production. A simple scheme for tagging releases to production is to use git tags with timestamps. It is also a must to script your deploys that way they are repeatable. An additional benefit is now, if we want to do continuos deployment to a pre-production environment, we have scripts to do that. An example deploy script is below: