Skip to content Skip to navigation

Jamie C. Tsui's Blog Posts

Jamie Posted by Jamie C. Tsui on Thursday, June 23, 2016 - 1:16pm

Three days after Stanford’s commencement on June 12th this year, we quietly launched a completely new website for Stanford’s School of Engineering. From start to finish, the web project took 10 weeks. This project included new design, new feature development, content migration, and feature and browser testing. In the end, the site launched smoothly with no downtime. 

Its success with an aggressive timeline can largely be attributed to two factors: 1) the agility and dedication of a high-performance project team; 2) the conscientious design and technical architecture decisions that Stanford Web Services made previously on the product on which the new site is based: Jumpstart Engineering.

Old School of Engineering Homepage

    Previous School of Engineering homepage

Addressing The Need

The previous Stanford School of Engineering (SoE) website used Drupal 6 as its CMS, which reached end-of-life on February 24th, 2016. With no active development on a replacement website, each passing day the School of Engineering's previous site presented a growing security liability and technical debt. Furthermore, the previous website had an outdated design -- it first launched approximately 6 years ago -- that was not mobile friendly in an era where currently 30% of the website’s traffic comes from mobile devices.
To address the immediate, practical concerns of the website, the project team within Stanford Web Services (SWS) collaborated with School of Engineering stakeholders to develop the “Quick Strike” plan: to leverage a website product previously developed for the School of Engineering and launch a new school website in less than 3 months.

Jumpstarting Engineering

Stanford Web Services has a core product line known as Jumpstart, a Drupal 7-based “website-in-a-box” that is available to Stanford organizations, such as departments, labs, centers, and programs. In Spring 2015, Stanford Web Services formed a partnership with Stanford’s School of Engineering to develop a Jumpstart product that would cater towards SoE “PICAL” groups -- Programs, Institutes, Centers, Affiliates, and Labs -- to address a growing need in the SoE community for a scalable, secure, mobile responsive, and Stanford Engineering-branded web platform. 
After a pilot with 5 trial groups in Fall 2015, Jumpstart Engineering (JSE) was released to the SoE community in February 2016 and is available for free to any SoE organization.

Leveraging JSE

JSE was designed and developed with PICALs in mind, with features and a site architecture structured around people, courses, publications, research, and resources -- content that is very different than what would be the focus on a school’s website: news, events, admissions, alumni relations, and more. 
To meet the aggressive timeline of Quick Strike, we knew that we could and should leverage the existing framework that JSE already provides: data models, features, mobile responsive homepage and page layouts, branding and styles, authoring roles, security (through upgrading to Drupal 7) and more. After an evaluation of the gaps, we estimated that JSE would fulfill over 80% of the needs for a minimum viable product (MVP) for a school site. 

School of Engineering Homepage

    New School of Engineering homepage

The Plan

To fill the remaining 20% gap between what JSE offered and what the stakeholders envisioned for a new, launchable school website, the project team defined areas of improvement that offered the highest return on investment, segmented into “Minimum Viable Product” (MVP), defined as a site launchable with 0-days notice:
  • New custom website theme that focused on color and typography changes
  • New masthead design on top of an existing JSE homepage layout
  • Integration with the Community Academic Profiles (CAP) system for automatic people information management for 275 faculty profiles on the website
  • Streamlined and simplified site architecture, and culled over 230 outdated pages
  • Separation of intranet onto its own site, simplifying permissions, maintenance, and navigation
  • Migration of all core school site content: homepage, news stories, faculty profiles, admissions information

and “Minimum Lovable Product” (MLP) reach goals:

  • New design and features for news, which affected over 900 news stories
  • Implemented an improved search solution, Apache Solr
  • Migration of secondary school site content: faculty awards, student programs, and other tertiary pages

The Execution

The Quick Strike process embodied the essence of agile and scrum. In addition to the standard sprint framework of scrum (with sprint kickoffs, reviews, and backlog grooming), the team also embraced the tenet of self-organizing sub-teams to quickly tackle tickets and smash blockers. As project manager and scrummaster, it was my responsibility to communicate clearly and closely with the project team to understand and remove all impediments, including reprioritizing their other commitments and removing them from any meetings they weren’t necessary to attend, and to also maximize their focus/productive time.

Screenshot of Stanford Engineering News page

    New news listing page

Because we operate on a 2-week sprint cycle, there were only 5 sprints available for the project from kickoff to launch and therefore intra-sprint meetings within the team were essential to move and communicate quickly. In addition to daily team morning scrums, we also added an end-of-day scrum on our “focus days”/”no meeting days” (Wednesdays). Furthermore, we had dedicated working meetings on Mondays and Tuesdays to facilitate communication and quick resolution of questions or issues that arose mid-sprint. 
At the end of each sprint, I evaluated our progress and coordinated with the product owner to adjust priorities as necessary. And once we were 1.5 sprints (3 weeks) away from launch, the requirements for bringing into a ticket into a sprint became more stringent: each ticket had to pass validation: “Is this a blocker to launch?” or it would not make it into the sprint.

The Launch

Prior to launch, we conducted cross browser and mobile testing, accessibility testing, and quality checked the content several times. Our developer handling the launch coordinated with the various other IT infrastructure and administration groups around campus to ensure that the necessary people were on standby during the launch in case any mishaps occurred, and that a contingency plan was in place for each point of failure. 
During the launch, there was an issue with securing and transferring the virtual host (vhost) for the site, and we followed our contingency plan successfully with no downtime. After the vhost issue was resolved, our developer quickly re-coordinated the teams to reattempt the launch.
Three hours after the originally scheduled launch time, we smoothly launched the new School of Engineering website to the world.

Screenshot of redesigned news story page

    Redesigned news story page

What’s Next?

Since launch, we’ve had over 16,000 visitors with 42,000 pageviews and to our pleasant surprise, have not received any notice of complaints and issues. Anecdotally, the reception of the new site by the SoE community has been positive. 
Our mobile device visitor ratio has increased by 15% since launch (from just under 30% to now over 34%), which reflects positively on our improved mobile experience. 
We plan to continue to monitor the traffic and stability of the site, and will compare the analytics pre-launch vs post-launch to look for trends. Having accomplished everything we had planned to address with Quick Strike MVP and MLP (security, stability, mobile-responsive design, improved search, improved faculty profiles), the stakeholders and development team can dream big from scratch for Phase Two work on the school site, and also rest assured that Drupal 6 end-of-life risks have been mitigated in the meantime. 
Quick Strike was the quintessential result of agile, scrum, lean startup, and MVP practices, and was also one of our team’s most ambitious and aggressively timed project to date. There were many firsts accomplished with the project that came as a result of not just “failing fast,” but also “recovering fast,” and the success of Quick Strike reinforced the benefit of our team’s early investment in developing a scalable product and platform. 
Look forward to our next big projects leveraged from Jumpstart!
Jamie Posted by Jamie C. Tsui on Friday, February 12, 2016 - 12:25pm

Stanford Web Services serves a diverse set of clients throughout Stanford University, ranging as large as schools to as small as individual labs. With over 200 active or completed website projects, and an average of 18 new project inquiries per month, we needed to implement a Customer Relationship Management system to track all of our operational data and communications.

Which CRM?

Last year we evaluated 7 different CRMs, including: Insightly, SalesForce, Zoho, Sugar CRM, HubSpot, RedHen, and Podio. After analyzing each of the options through an evaluation matrix based on our needs, we settled on Podio for our team. It has now been over 7 months since we’ve migrated all of our data from disparate systems into Podio, and the reception has been very positive across all roles in the team. We were able to consolidate various types of information from Basecamp, Google Docs/Sheets, Excel files, email, mailing lists, and even information that only existed in our staff’s memory.

Importing and Setting Up Your Data

One of the critical requirements for adding a CRM to our operations was its ease of data import and export. Podio, at its core, can be thought of as a UI on top of a relational database, so we found it extremely flexible and customizable for our needs. It’s quick and simple to import and export data in Excel format. We set up several “apps” for each of our types of data: an “app” is similar to that of a Content Type in Drupal, though simplified. We have apps for our leads, organizations, projects (completed and in progress), website launches calendar, help tickets, products (we have several product offerings, including the Jumpstart product line), potential deals (new inquiries), website theme information, vendor contacts, and more.

Connectivity and API

Using Podio’s “Email API”, we were able to easily integrate a number of other systems to feed data into Podio. Although Podio has built-in support for webforms, we use Qualtrics to create web forms with question display logic and email triggers to customize the data that gets fed into Podio (such as for help tickets or new project inquiries). We’ve also used ZenDesk’s triggers to pass help ticket information from one of our partners to Podio.

By having all of our operational data in one system, we were able to improve our operations across the board, from the intake level all the way through to the support level. We can take a look at an organization’s listing and easily see all of our active and completed projects with them, their related help tickets, a list of new project inquiries from them, as well as the potential value of those new projects.

The inbox is not where you store communications

Another one of the primary goals for implementing a CRM was to record communications more visibly and permanently as opposed to in an individual’s email or via a mailing list. Within each of these items in Podio, such as a single project, or a single help ticket, Podio allows users to add comments and attachments via an “activity stream”. This feature essentially improves coordination and communication within the team: such as if someone needs to take over a deal consultation from another team member and wants to read all the past communications with that client. To do this, our team member would simply CC or BCC the “Email To Item” email address provided by Podio for that specific item. This process also ensures information retention for the team. Changes to fields within an item are also tracked in the activity stream, allowing us to see who made the change and when.

A single point of reference

Podio serves as first point of reference for information: from there, we can link out to a project’s relevant Harvest listing, JIRA project, Basecamp listing (if applicable), as well as links to a project’s development and production site URLs. Since implementing it with our operations, it has saved countless hours of searching and coordination, as well as improved communications and information awareness within our team.

Have you looked into CRMs for your team, or do you use one already? How has your experience been? What are your favorite features from your CRM?

Jamie Posted by Jamie C. Tsui on Thursday, October 29, 2015 - 2:05pm

While Stanford Web Services can be seen as a service provider, often involved with custom projects and closely working with clients, one of our core offerings is also our Jumpstart product. With any product offering company, as adoption and usage of the products grow, more and more customers give feedback and express interest in the future direction of the product. Lately, our group has been contemplating increasing transparency in our product development roadmap, and to what extent.

To be or not to be transparent?

On one level, transparency and inclusivity in the design/development process can turn into a “design by committee” process, potentially paralyzing development in an effort to satisfy numerous specific/one-off types of needs. This is one of several reasons as to why many companies choose not to make their product roadmap public, and to use a “take-it-or-leave-it” approach in whether or not customers adopt their product (Apple and Facebook in particular come to mind). An advantage of making the product/development roadmap more opaque is that customers remain likely to purchasing/adopting the product late in its lifetime, instead of postponing their purchase for the next generation product to wait for better features. Furthermore, especially in competitive and NDA-heavy industries, opaqueness in the product roadmap is necessary to gain competitive and first-mover advantage. 
On another level, transparency can be very valuable; it creates a sense for clients that their feedback and input have been heard, and for companies it increases predictability and stability within its customers' purchase habits. For the company, it is a way to gauge customer reception of the product without actually committing to building anything yet. “Leaks” and concepts/prototypes are a common method of creating hype and gauging potential adoption, especially in industries where there is a significant investment in resources to bring a product to market (see: the auto and tech hardware industry).
For a product that requires a significant investment (in both time and money) on behalf of the customer, such as a consumer camera and lens ecosystem, having a product roadmap increases the likelihood of customer adoption earlier in the system since they can expect that their investment in the ecosystem will be sustained and improved upon in the future. In the case of the camera/lens ecosystem example, customers can have confidence that new releases of lenses will be compatible with the customer’s existing camera, and also that new releases of cameras will be compatible with the customer’s existing lenses. This customer confidence encourages earlier adoption into the system, bringing in revenue earlier to the company for re-investment in developing and improving the product ecosystem.

"Transparency empowers teams"

Transparency often benefits the internal teams developing the product by providing a vision for team members to follow, and by reducing hearsay, confusion, waste, and complexity. Team members feel empowered when they are “in-the-know,” and also appreciate being part of the conversation and having a sense of ownership, ultimately leading to higher morale. This must be balanced with transparency to the company’s customers, with a level that is just enough sufficient to ensure that customers feel that their concerns are heard and that they are also fairly prioritized. The level of product development transparency a company chooses to reveal to customers ultimately depends on the business goals and the type of product that the company produces. 

Increase transparency gradually

Lastly, one important consideration to note is that it is difficult to renege on a level of transparency once it has been established. Roadmaps are constantly evolving, and customers can lose faith in the company if something is promised and then later deprioritized. Therefore if transparency is the plan for the company, it is best to incrementally increase levels of transparency to clients in order to gauge the level that is appropriate for both the company and for its clients. 
Have you considered increasing transparency to your clients with your product development and operations? Did your clients find it useful?
Subscribe to Jamie C. Tsui's Blog Posts