Architizer Source

  • Company: Architizer

  • Platform: Web

  • Years: 2014 → 2016

  • Role: Product Designer & Product Manager

  • Design Team: 2 Designers reporting to Chief Product Officer

 

A new kind of marketplace

In the early spring of 2014, Architizer attempted to create a consolidated resource for architects to find products for the projects they were working on. This idea flopped mostly because it was almost impossible to keep a database like that up to date (with our meager resources), since manufacturers weren’t willing to give us products in a standardized format. As soon as an architect would see that we didn’t have a product they were familiar with, they wouldn’t consider using the database.

So we decided to flip the script. Instead of creating a database for architects to view products, we wanted to create a system whereby architects could communicate with manufacturers. Manufacturers are happy to communicate with architects, and often need to in order to discuss how their product can integrate into a building. Architects sometimes even rely on manufacturers to understand which kind of product they might need to solve a problem they’re having on a project.

We gave the project the codename “Source” and decided we were going to put the right process in place to make a product that would be based on how the architecture world actually operates, using research, testing, and conversations with expert partners.



Figuring out the details

So the team when upstate for a week to workshop how this new product might actually function. We had all of the heads at the table: business, sales, operations, technology, and design. We started all the way down at nomenclature. What do we call the various parts of the industry and this product. And we went all the way up to how we could operationalize the communication between architects and sales reps.

From there, we made flow diagrams which would represent how the product was meant to work. We had to keep in mind that architects and sales reps needed to talk with each other at the product level although the architecture project overall was something that the architects in were thinking about. So the way we chose to structure the application on the architect side was to have them create projects where they could list out all of the products that they would need. They could edit those product requirements and ultimately send those as opportunities for the sales reps to propose solutions for. On the sales rep side, they would have a list of product opportunities and each of those product opportunities would include the descriptions about the overall project. Once and sales rep found an opportunity that matched their business, they would be able to respond with a product they thought made sense along with a message.

I put together mock ups and flow charts which represented this process. This helped us to think more deeply about what kind of information we would need from both sides of the marketplace. Eventually we had a full set of designs which represented how an MVP version of the product could work. We collaborated with the engineering team so they could quickly start to piece together the backend of the product.

What we ended up with was a highly usable and testable MVP. We went to different product manufacturing brands and talked with their sales reps about how they might take advantage of a product like Source. We also went to architecture firms to pitch them on the idea of joining Source while gathering feedback on the product itself. Through these conversations, we were able to continue to update and iterate on the MVP. We were also able to internalize the concerns of the types of customers that would be using the product.

Testing and improving

After Architizer Source launched, we continued to add more functionality and features including the ability for manufacturers to be able to create products that they could reuse for future opportunities. This both helped to speed up sales rep response time, as well as to help us understand when a product was being used multiple times.

Architizer Source had the opportunity to continue to mature overtime. I worked at Architizer for over two years so towards the end of my time at the company, I was able to think about ways for Source to be more optimized for both architects and sales reps. Ultimately, Source was a communications platform. We had originally conceived of it as a request-for-proposal type of system. But, in reality, architects and sales reps were communicating back-and-forth continuously.

I proposed that the platform should revolve around an ongoing communication thread between the two sides of the marketplace. The conversation would be oriented around the product that the architect was looking for. But the sales rep wouldn’t be limited to just proposing one product or one solution. Instead, they would be able to have a natural dialogue between the sales rep and the architect which would allow the sales rep to better understand what the architect was looking for and propose multiple alternative products. This re-conception of the product was based on months of conversations with architects and sales reps.

After I left Architizer, Architizer Source continued to be the main focus of the company for sometime.