The Secret Sauce, Ep. 29: Benefits of an Iterative Design Feedback Process

August 30, 2016

In this week’s episode of The Secret Sauce, Senior Designer Ashley Cyborski discusses our iterative design feedback process and how this helps move designs forward to effectively meet our clients’ ideal results.


Allison Manley [AM]: Welcome to The Secret Sauce, a short podcast by, that offers a short piece of advice to help your business run a little bit better.

I’m Allison Manley, an Account Manager here at Palantir, and today we’re talking with Ashley Cyborski about a good design iteration and feedback process.

Ashley Cyborski [AC]: Hi everyone,

My name is Ashley Cyborski and I’m a senior web designer here at Palantir. You may remember my other podcast about the benefits of designing in the browser. You should check that one out if you’re a web designer feeling hesitant about taking the leap to HTML and CSS.

Today, though, I want to talk about our design feedback process here at Palantir, because it is a bit different than traditional design processes.

I’d like to rewind and give you a bit of background. At Palantir we use agile methodologies during our development process. For anyone unfamiliar, agile is a 2 week cycle called a sprint where you prioritize work, complete those tasks, present the work to the client, and receive feedback which you can then incorporate into the next sprint. It is a process of continual improvement and collaboration. Our design feedback process came out of a desire to incorporate that same level of collaboration and continual improvement into the design phases of a project.

After a lot of thinking, and quite a bit of inspiration from a webinar by Dan Mall, we came up with a process that is iterative, but accommodates our clients’ needs.  The process isn’t perfect and we are continually working to improve it, but it is a huge improvement from where we were just two years ago.

The core principle of our design feedback process is iteration. Though this sounds pretty obvious, it is very different than the traditional design feedback and iteration cycle. In a traditional process you present your work, receive feedback, incorporate that feedback into the design that you had presented, and then re-present your work, around and around until the client decides to approve the design. And though that works quite well for print design, it is counter intuitive to web design, especially when paired with an iterative development process.

In our feedback process we often tell our clients to think about moving designs forward. At the start, we present 2 to 4 style tiles to the client. Then, we ask them to choose the “most correct” one to move forward with. The one they chose may not be perfect yet, but through iteration and with the proper input, we move the design closer and closer to that “ideal”.

In order to get there, we need that input. We ask our clients to provide feedback on the chosen style tile and the discarded ones. We prompt with questions like “What did you like about this design?”, “What don’t you like about this design?”, and most importantly, “Why?” Our goal is to understand our client’s thoughts and feelings, including what is inspiring them and what is concerning them.

We take all that feedback and the selected direction, and begin on the first static comp. We don’t spend our time iterating on the selected style tile.  At this point we repeat the process with static comps. The feedback received during the comp phase is worked into the prototype. From there on out, the prototyping process syncs up with the sprint cycle, and feedback on prototypes is defined and prioritized along with the remaining design tasks and incorporated on a sprint by sprint basis.

That was a lot of words to describe how we move the design process forward. You might ask, why don’t we work on one deliverable until it is “perfect” or close to perfect? Well there are a few driving factors.

First, our process becomes faster and more efficient because we don’t have to pause the project to work out small, inconsequential details that would otherwise resolve themselves in the future. The entire project doesn’t pause until we get it to some subjectively “perfect” state of design. This is important and unique to web design, because your design will appear on any number of machines, browsers, screen sizes, and with multiple variations of changing content over the course of its life. A website is a living, breathing, changing thing.

Second, we can adjust the course of our design as the project moves forward and develops. We aren’t stuck with a decision we made in week 1 of the project, when we learn something new in week 7.

Development prioritization can drive design prioritization and the design benefits from active and informed developer feedback and input. This benefits the designer, because we aren’t completing work that ultimately will not be implemented, and benefits our clients because they aren’t paying to design work that ultimately won’t be implemented.

Third, we get to the browser faster which benefits both the client and the project. I track some of these in a blog post about designing in the browser, but I’ll recap the main points here.

Clients tend to understand designs better once we get into the browser because they are more realistic and interactive which helps clients provide better, and more relevant feedback. In browser designs also foster more productive communication and collaboration with developers and reduce duplicated work. Additionally, designers have more control over the final, implemented design.

Finally, and possibly most important to the feedback process, it is easier to implement feedback and iterate on the design system in code than it is across multiple page comps. The feedback changes are instant, consistent, and more efficient.

Ultimately, this means that the client is able to provide more realistic and relevant feedback, which can be implemented and iterated on faster and more efficiently, all while the design process flexes and flows with development’s needs and prioritizations.

I think I’ve outlined a lot of the benefits of our forward moving design process, but I should caveat that we are still iterating on this process to make it even more efficient and effective.

One of the major gaps in this process right now is client education and buy in. It is often hard to convince a client, with little to no experience with web design, to adjust their preconceptions about the design approval process. It is also hard to get buy in, for example, that the homepage static comp does not have to be “perfect” in order to move onto the next deliverable. Clients fear that their feedback will be lost or forgotten or that it isn’t being taken seriously, when they do not see it implemented immediately. Clients often tend to be relatively uncomfortable moving forward with something that is not “Approved” or finalized for these exact reasons. One way we try to counteract that is with documentation, making sure we track and the requests changes and tickets.

It is up to the designer to communicate as best we can the benefits of this process to our clients upfront. I really believe that ultimately a client gets a better, more flexible end product when using this process.

I’d love to hear other’s experience with a similar process. Whether it is an issue you’ve run into and solved, or just with your own experience with a similar process as a client or designer. Leave a comment on this post or tweet to me @AshleyCyborski.

AM: Thanks for listening to this edition of The Secret Sauce. You can find more great tips on our brand spanking new website at, and you can also find us on twitter @palantir.

Enjoy your day!


The Secret Sauce, Ep. 28: Project Stewardship and Understanding KPIs

August 23, 2016

On this week’s episode of The Secret Sauce, Joe Allen-Black and Luke Wertz explain how Project Stewards use a collaborative process to help our team fully understand and meet our clients’ business objectives and goals.


Allison Manley [AM]: Hi everyone, and welcome to The Secret Sauce, a short podcast by, that offers a quick bit of advice to help your business run a little better.

I’m Allison Manley, an Account Manager, and today we’re talking about Project Stewardship with Joe Allen-Black and Luke Wertz.

Luke Wertz [LW]: Hello, I am Luke Wertz. I am an senior engineer and a team lead here at Palantir.

Joe Allen-Black [JAB]: Hi, I’m Joe Allen-Black. I’m a project manager and a strategist here at Palantir.

LW: So today we wanted to take a few minutes to talk about this concept of project stewards that we have here at Palantir. When we’re planning out a project and planning for a project’s success, one of the first things that we do is try to identify individuals within our project team who will be responsible for ensuring a project’s long-term success, from the very beginning all the way through completion of the project.

JAB: What we want to make sure is that the success is defined not only by the fact that the website does everything that they hope and want it to do, and we’re able to feel great about the work that we can do, but we also want to be sure that we’re doing it within the budget constraints, within the time constraints, within whatever kinds of issues happen to be coming in — we want to make sure that we’re making the best site for all the different situations that we have.

LW: Yeah, exactly. We have come to this point of trying to identify two people to do this, from a long history of only having one person that tried to embody this from the beginning of a project to the end. And that person ended up going through some unusual changes during the course of a project, needing to wear many different hats: the business analyst hat, sometimes just having to refer to that person as an analyst, sometimes as an architect, sometimes as a technical lead, sometimes as a team lead — it got to be a bit much. And it was oftentimes difficult to transition well from the strategic planning parts of a project, that typically happen quickly very early on, and then into architecture and technical implementation. So we identified that this need arose to have two people playing this part on a project, and to work as a balance and counterbalance for each other.

JAB: What we’re ultimately trying to do is make sure that throughout the process our clients understand why we’re coming up with solutions, why we’re coming up with suggestions, as to how we can best work with them. And during the types of projects that Luke and I are on, part of my role would be to go through and determine some of the different features, some of the different ideas that we want to have the site include. And then, working with Luke, I’ll try to help facilitate the best way we can implement those in maybe the best order for those. The technical side is left to smarter folks like Luke to figure out, obviously. And then we try to make sure that together that the options are the highest-quality technical answer that fits within the constraints we have on the project.

LW: That’s exactly right. We spend a lot of time talking about what our client’s business objectives are, and their goals. And where I really rely on somebody like JAB, or somebody in JAB’s position, is to really have a deep understanding of the client’s KPIs and what those might look like in practice. And having somebody who is a co-worker and colleague who does that, and not being reliant on a client stakeholder to do that for me — it allows me to workshop ideas and to architect these incredibly huge, sometimes overly complex — some might be so bold to say, over-engineered solutions, and have a friendly face telling me, nope, go try again.

JAB: It’s friendly sometimes, you know, depending on the type of project [laughs].

LW: It’s always done in love [laughs].

JAB: We want to make sure that, when we come back to our clients and make a recommendation, we’ve been able to talk and that we understand the vantage points of both of us, and that we’re able to go, considering what we want to do. We know that we should spend a bit more time on making sure your workflow is the best, because that’s a pain point to you, and we might do that rather than spend a lot of time on some other part of the project. Or depending on the project it might need to be made sure that speed is in there, or that there’s something else that needs to be enhanced, and that might have to come at the expense of spending time on something else. What Luke and I are able to do is to make sure that we’re really keeping each other in check, and then we bring back the best possible options to our clients, to make the ultimate decisions on how they want to spend their budget and want to spend their time, but knowing that they’ve got great feedback from two folks looking at it from different vantage points.

LW: So what this looks like in practice for us is, starting from the first inkling of a project, when we’re still just in the very early stages of talking with a client about the potential of what they want to build, we will assign two people as a strategist and as a technical lead. And it is their job to be involved from the very first conversations we have about the actual production of a site to sit in together and to hear the same things from their own unique expertise, and to be able to hear from the clients and the many stakeholders that are often involved in those early conversations, so that we can fully encompass both the business needs and the technical needs that may be constraints or desires on the project. So we start this process early on, and build a very collaborative process where we’re checking in very frequently, we’re documenting separately the things that we hear, and then bringing our notes together and making sure that we’re hearing the same thing and are able to capture the same vision for what the final product is going to be.

JAB: Then throughout the beginning of the process I might be introducing different concepts for how we want to organize our data, how we want to have different pieces of the site speak to different audiences, while Luke is giving ideas on how we would structure that data, how we would be able to put that in a way that, at the end of the day, somebody’s going to be able to see that on the Internet or whatever type of tool that we’re building. And as that continues going on, we work with our client to get to the best ideas. As his team keeps working through the development, my goal will be make sure that I’m able to follow up, can take a kind of different view of it, gut-checking, to make sure it’s working the way we were expecting and for the right goals.

LW: So we’re both definitely involved from the beginning and throughout. But the place where our two separate disciplines and our mutual responsibilities as stewards on a project intersect is at the data model layer, which is a very developer-y buzzword. That’s my word, not JAB’s. But the output of our data model is typically a complete definition of all of the pieces of information that are going to be on the project, and what those pieces of information encompass. And so Joe has worked very hard up to that point to get a full understanding of the individual pieces of information that are necessary to meet the goals and KPIs of the project, and I’m working alongside him to define reasonable ways of storing those pieces of information in a well-defined database and data structures. And so the output of that process is a data model that the development team can then use to begin layering interactions and relationships, and begin to see the vision of the full thing come to fruition.

JAB: It’s definitely measure twice and cut once. So we’ll spend a lot of time talking about, what are the types of pages that we need, what are the types of elements, and then how do we break that into fields and how do those relate. So I will be talking with the client or with the people that we’re working with, and saying, hey, we really need a categorization that helps us bucket these items together. Or Luke will take that, and using a term like ‘data modelling’, turn that into what that’s going to look like on the back end, and how can we be sure that we don’t blow up the element by putting a bunch of code out there. So we’re able to have that approach in two different ways that ultimately hits that goal.

LW: At the end of the day, what we want to make sure is that any client we’re talking to, any client that we’re working with and trying to build a project for — we want to make sure that we have the right people around the table or the Google Hangout, as the case may be to make sure that we’re hearing correctly and exactly what the client needs. Because it’s not until we can fully understand what the client needs that we can build for them exactly what they want. So that’s really the role of the project stewards: it’s to be there at every moment of the project to ensure that we’re hearing and we’re listening and we’re responding appropriately. Thank you very much.

JAB: Thank you.

AM: Thanks Joe and Luke. That’s the end of this week’s Secret Sauce. For more great tips, check out our website at, and check us out on Twitter. Our handle is @palantir.

Have a great day!


The Secret Sauce podcast, Ep. 27: A Peek at Drupal GovCon

August 16, 2016

On this week’s episode of The Secret Sauce, we are joined by guests Kirsten Burgard and James King, organizers of Drupal GovCon.


Allison Manley [AM]: Hi again everyone, and welcome to The Secret Sauce, a short podcast by, that offers a quick bit of advice to help your business run a little bit better.

I’m Allison Manley, an Account Manager, and today we have a different Secret Sauce. Ken Rickard, our Director of Professional Services, recently attending Drupal GovCon in Washington DC in July, and got to sit down with two of the organizers: James King from the National Institutes of Health (NIH), and Kirsten Burgard from the US Department of State to chat about this annual Drupal event. So they are going to share what this event is about, and why you may want to check it out next year.

All right! Take it away Ken . . .

Ken Rickard [KR]:  This is Ken Rickard. We’re at the Palantir Secret Sauce podcast. This is our broadcast from Drupal GovCon, and we’ve invited two of the organizers to join us today: we’re with Kirsten Burgard and James King.

Kirsten Burgard [KB]: Yay! Welcome to Drupal GovCon.

KR: Thank you. This is I think my third or fourth . . . it used to be Capital Camp, and it’s now GovCon. This is the second year I’ve been here at the NIH, I know that. So tell me, how did the two of you get involved in this event?

KB: Well, it started . . . this is all really Tim Wood’s fault. He’s at the Department of Commerce. And he thought it would be really great if we all got together and started to do events, mini events where we could share information. The very first event one we did we had thirteen people. Then we decided to hold a larger event as a government-focused one at Commerce, and that was 2012.

KR: Yes, I was there,

KB: Yeah, we killed the wifi before 8:00 in the morning [laughs]. I had never seen that before. We thought we’d get about 200 people. We had 330. And at that event James approached me and said, “Hey, what about NIH hosting it?” And I thought, ‘this is never going to happen. Who at NIH is really going to make this happen?’ And it’s been James for three years now.

James King [JK]: So I did go to the Commerce event, and I had started using Drupal since 2010. When I got hired here in 2009, they gave me a project that hadn’t been started, and they bought this thing called Drupal and had a server, and I knew nothing about Drupal so I was learning on my feet Drupal 6. And I started playing with it and really liked it, and wanted to learn more about it. Found out about the Commerce event and that, like what was there, but saw how cramped it was.

KB: [Laughs]

JK: And wanted to get involved, and also selfishly wanted to be able to get more exposure at NIH on Drupal. I work for the NIH Library . . . the internal research library for NIH . . . and one of the things that we’re trying to do is foster community in different areas. And since I have a technology background, I’m trying to encourage use of technology across NIH. And Drupal being one of the things we’re working on, we were trying to encourage more people to know about and use Drupal.

So it made sense to at least try to have an event at our place. Since then obviously this has continued to grow, and we now have user group meetings as well just for NIH people. And those are growing as well.

KR: Yeah, the GovCon is a little bit of a special event of all the ones that I go to. Most of the ones that I go to are regionally-themed, but this one is industry-themed, or in this case, government service.

KB: Yeah.

KR: Public service themed. So, I mean, what are the goals of the whole idea? What are we trying to accomplish here?

KB: Well when we started doing DrupalGov . . . it’s actually called Drupal For Gov . . . we really just wanted to make it possible for government practitioners in open source communities to get together. Drupal just had the largest influx of folks within government. We also have Linux people, Wordpress people, Joomla people. We have a wide cross-section of open source CMS’ mostly, and some back-end things. And our primary goal was to make it possible for government employees to get access to the information they needed. Whether it was training, or collaboration, or even just innovative new thoughts and processes.

Oftentimes in government we’re very stove-piped. We don’t collaborate, we don’t cross sections. We don’t . . . even within my old agency, Department of Veterans Affairs, one section didn’t talk to the next section. It’s very confrontational almost between offices. So to make an organization like ours, which started with 11 people, to an event that now has over 1,000 people attending, is pretty weird [laughs]! It’s just pretty darn weird.

JK: So as a librarian geek or information professional, information architect, I very much embrace the idea of open source, but also government use. The government spends a lot of money with contractors developing themes, developing modules, so forth, at a minimum I wanted to try and bring together the NIH people to be able to share that. To not only share the products, the deliverables, but to share lessons learned, to share the modules they’re using, tips and tricks, to come together on training, and so forth. Drupal GovCon was an easy way to foster that.

Having it here on campus made it very easy for the NIH people to come, but we’re also trying to be a sharing, open environment, so we’re making it as broadly available as possible. That’s why we continue to try to keep it to be free so that any level person, whether they’re a budding sysadmin, or developer, or a UX person, we’ll be able to come and learn.

KB: And we’ll have something for them too. We have sections that aren’t just like the regular “here are the tracks,” but actually sections across the board, and on top of that, additional training too.

KR: Yes, it’s a very interesting lineup. You have a very diverse speaker group, and very diverse attendee group. It’s interesting too, a lot of the Drupal events are weekend events . . . this is during the week. And so it’s almost a professional event. I think that’s fascinating too.

So based on the success we’ve seen from the last few years, I was at the Commerce event, what are you hoping to see next year?

KB: So next year might be a little bit more difficult because like I said, we’re over 1,000 now. Our attendee drop is nowhere where it needs to be on a free event. So typically a free event will have like a 50% drop in attendance over registration. Ours hovers at less than 40%. That makes it much more difficult for us to gauge how many lunches to buy, how many cups of coffee we need . . . we ran out of coffee yesterday morning an hour into coffee service, and we bought 800 cups! We ran out of lunches really close to the very end, so it wasn’t as like a lot of people had to go buy lunches. I believe we ran out of lunches again today, but not badly . . . only a couple.

JK: No, we were pretty close. The auditorium seats 500.

KR: And that’s the biggest space we have available.

KB: Yeah. And what we do through the day is we flux space everything. So we try to  tell all the attendees, “Please, refresh your screens. Sessions will move.” And they do. And sometimes speakers forget where they’re supposed to be.

JK: I appreciate and I expect that we’ll continue to have that diversity as highlighted in our keynotes. The first day keynote was challenging attendees to really look at diversity and bias that’s in the industry, and how do we step back and address that. Today was more of a practical on how do we practically move an agency top-level site to Drupal. And tomorrow . . .

KB: Tomorrow it’s all security. We actually have the keynote from Velocity from last year, Laura Bell, who is a security expert from New Zealand. So I’ve had all kinds of fan boys come up to me and say, “oh my god, how did you get Laura Bell?” and I’m like, “I asked.” [laughs]

KR: That might be the lesson for folks to takeaway from this episode of the podcast is sometimes all you have to do is show up and ask.

KB: Yeah. Show up and ask. It works really well.

KR: All right. Thank you both for joining me.

KB: Thank you.

AM: That’s the end of this week’s Secret Sauce. For more great tips, check out our website at, and check us out on Twitter. Our handle is @palantir.

Have a great day!


The Secret Sauce podcast, Ep. 26: Key Elements for Project Success

July 22, 2016

In this week’s episode of The Secret Sauce, Director of Professional Services Ken Rickard gives an overview of his upcoming webinar that outlines the components that go into successful web projects.


Allison Manley [AM]: Hi again everyone, and welcome to The Secret Sauce, a short podcast by, that offers a quick bit of advice to help your business run a little bit better.

I’m Allison Manley, an Account Manager here, and today’s advice comes from our Director of Professional Services, Ken Rickard. He has some thoughts on why web projects succeed: how to do proper planning and how to consider all the components of a project.

A heads-up that he talks about a webinar he’s hosting on this very topic on Wednesday July 27th, but in reality we moved it to Thursday July 28th (the next day)! So be sure to join our mailing list on our website at, or email me at to get the information and get the link forwarded your way.

All right! On to Ken . . .

Ken Rickard [KR]:  Hi I’m Ken Rickard, I’m the Director of Professional Services at, and on the 27th of July [NOTE: moved to the 28th of July] I’ll be doing a webinar called “How Web Projects Succeed” in which we’ll take a look at how you plan, and then later execute, a project from end-to-end. And we’ll be looking at specifically all the different components that you need to be thinking about in terms of strategy and budget while you’re planning to do your next project.

So what we like to do is walk through all the necessary steps that are required in order to really get a firm grasp on the goals of the project: how you’re going to measure your success towards those goals, how you’re going to articulate those goals to your internal stakeholders, we’ll talk about how you develop personas and other understandings of your audience, how you use those to inform your design, and use those again to do some testing around those designs to make sure you have good information architecture. We’ll talk about content, in particular we’ll talk about content audits and content strategy, so that you understand how your message gets across in terms of your CMS architecture, but also workflow and all the other little bits and pieces that go into making a successful editorial experience.

So what I think you’ll find for people who don’t do . . . who aren’t in a web firm like ours who do dozens of projects in a year . . . you’ll find there are lots of little nuances and details that if you’re not planning for them, they will catch you by surprise. And if you’re not prepared for those surprised, you’re going to have a difficult time adjusting as the project moves on.

It’s a fairly informal talk, but we do drill into, “here are the things we know are going to happen, here’s what we advise are best practices, and here’s how you ought to be budgeting for things.” A good example would be if you’re not budgeting for quality assurance testing, what are you going to be missing out on? If you’re not budgeting for long-term support . . . it’s fascinating the number of people we run into who have a budget for getting a new site designed, but then have no budget for Year 2 or Year 3, thinking, “well once we do this, it will be done.” And that’s just not the way the web works! We’ve all been doing this for a very long time, and understand that the web is a dynamic medium, and the thing you just finished isn’t complete. There are just waypoints along the road of sort of ongoing marketing and development and things like that. So you are always in a position to want to make changes. You’re always in a position to want to publish new things. And in order to do that, you need a long-term maintenance strategy.

It’s interesting . . . I was talking to a client recently, and we had a very long conversation about how we could help them on their project. And it was interesting to me because I think they were looking for a technical answer. They were expecting me to give them a technical answer. And I said, “the three biggest things we can figure out for you right now are: what’s your editorial workflow? Because you’ve got 300 people stretched across 10 different departments who right now pass around Word documents in email. Then they go into the CMS and they go online. That’s Number 1.

Then Number 2 is what’s your governance plan going to be? And your governance plan is something that, again, people often overlook. And that’s about who can make what edits to content on the web, who has to approve it before it goes live, when does it expire, things like that. And your governance plan, along with your workflow, really dictate a lot of the architecture to how the CMS has to be built. In some cases it dictates which CMS you need to use, as some do things in one way and some in another.

And the third thing we talked about . . . again, I think they were expecting me to say, “here’s some technical expertise” . . . and the third question was: what’s your maintenance capacity? Because again, this was going to be a very large project for a number of different departments stretched across a number of different agencies. And they have a staff of six people! So we could architect the greatest solution in the world, but if they can’t maintain it, then it’s not going to be a successful project.

So we use those kinds of metrics when we’re talking about success. What does it actually mean two years on? Three years on? After the initial project is done? How are you going to support it, how are you going to interact with it? How are you going to make changes as you go? Those things are critically important. We’ve done very successful projects where the budget constraint meant we couldn’t do the architecture that was recommended, so we had to go with alternative methods in order to keep the budget under control. We’ve done projects where we’d like to do a certain architecture, but they only have a staff of two, and the staff of two can only maintain certain things.

So if you understand going in all the different things that have to happen on a project, which is again what we’re going to be covering, these kinds of questions become much clearer, and much easier to answer. And that’s something I think we really enjoy as a company . . . I’m not the only one . . . everyone at Palantir really likes digging in and doing that kind of collaborative problem solving. That is easier to do when everyone knows, ok, these are the puzzle pieces, these are what we are trying to fit into a successful project.

And I would leave with this one thought, which is the big question I always like to ask people when we’re kicking off a project . . . and you can think about when going into this kind of session is: six months after your project is done and the new site is launched, what will you consider success to be? Typically we find people who are focused on one or two aspects on the project, and they may not be the right one. Sometimes people are fixated on budget, sometimes people are fixated on hitting a deadline. And that’s generally not enough because the things that are driving those budgets and deadlines generally have business goals attached to them. So you have to know, well, really we’re driving to have this project done by the end of November so that we can hit the big conference that we’re throwing, and then we’re hoping to increase our membership 20% in the three month after that conference.

That’s the kind of thing that you need to be able to come into a web project being able to articulate. Because that’s what’s going to drive the design and the development of the project. So understanding when you’re hiring a firm to do an end to end project like that you’re not just hiring, as we say in my house, you’re not just hiring us to lift the couch and put it where you want it. You’re hiring us to do the interior decoration, the interior design as well. And to do that we need to know what kind of living space do you want? What kind of tasks are you trying to accomplish? What kind of business goals are you trying to accomplish?

Like I said, that’s a whole lot to swallow! But I think we can actually do it. It’s a 45 minute session, and it’s free to attend. Go ahead and sign up, and we’ll be happy to see you on the 27th. {NOTE: moved to the 28th]

AM: But remember, it’s been moved to Thursday the 28th!

That’s the end of this week’s Secret Sauce. If you’re interested in attending Ken’s webinar on Thursday the 28th, please go online to Hope to see you there. Have a great day!


The Secret Sauce podcast, Ep. 25: What Can Support Do for You?

July 21, 2016

Web projects are a lot to manage, and that fact doesn’t change after launch. A dedicated support team can help keep things running smoothly and securely. Client Success Manager Cynthia Philpot goes over all of the services our support team can provide to make sure your project is a success, no matter the size.


Allison Manley [AM]: Hi again everyone, and welcome to The Secret Sauce, a short podcast by, that offers a quick bit of advice to help your business run smoother.

I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Cynthia Philpot, our Client Success Manager. Cynthia handles support for our clients, which is such a critical component of any website. Because once a site is finished, it still needs continuous maintenance and upgrades. She will be talking about the support services that we offer here at Palantir and how we can assist with your support needs.

Cynthia Philpot [CP]:  Hey Allison! Among the many other services that has to offer — like web strategy, consulting, designing and building some very cool websites, we offer ongoing client support.  

Whether you are transitioning into our Support department from an ongoing Palantir project, or if you are looking for an experienced company to support your existing website, we can address your needs.

As the Client Success Manager here at Palantir, I am the ongoing point of contact for all of our customers in Support.  Based on a relationship built on trust we interact on a regular basis to ensure enhancements, features, and other project needs are addressed.

The services that we provide in support are many. We like to begin with a site audit. The site audit is essentially a snapshot of your site. We do a technical review of the site, looking at things like the architecture, build, security — just to name a few. We then provide you with an audit report and walk you through the site findings. We provide information and recommend solutions about any urgent needs that we uncover and make short and long term recommendations to provide a roadmap for next steps. We can do the work for you if you like, or we can do a consulting or training engagement should you decide to do the work yourself. This is really beneficial for a number of reasons for a variety of different people based on their individual skill set levels and desired outcomes.

You will have unlimited access to our ticketing system, which our support team will monitor, evaluate, and use to respond to your requests. Be it a bug-fix, issue, or question, we will assign an experienced engineer to provide one-on-one assistance and work with you until the request is resolved.

We do security updates because keeping your site secure is at the top of our list. We check weekly for any security updates that may affect your site, and we’ll keep you informed on the progress and ensure the update is done in an expedient manner.

We can maintain a standing relationship with your hosting provider. So based on your specific issue and provided we have access, we gladly manage the relationship between you and your hosting provider on your behalf. We have standing relationships with most of the largest providers, and can assist in providing clarity when you receive important notifications and alerts.

I mentioned earlier that we perform a site audit but we also provide a Google Analytics audit to identify proper tagging, custom event tracking, goals, conversions, and any other customizations aside from a basic install.

As I mentioned early on, whether you need assistance maintaining a current site or perhaps needing to onboard a new employee, we can provide training to fit your specific needs. Palantir provides training and consulting in a variety of formats. Teaching is an integral part of our work.

We provide support for Drupal sites as well as other types of sites like WordPress too. If there are additional questions, I am available to provide answers and discuss pricing. Just give me a call.


AM: That’s the end of this week’s Secret Sauce. For more great tips, please check out our website at You can also follow us on twitter at Have a great day!


On the Air with Palantir podcast, Ep. 06: 20 Years of Palantir

July 15, 2016

Intro: Welcome to the latest episode of On the Air with Palantir, a long-form podcast by where we go in-depth on topics related to the business of web design and development. It’s July 2016 and this is episode #6. In this episode, Account Manager Allison Manley is joined by Palantir CEOs George DeMet and Tiffany Farriss.


Allison Manley [AM]: Welcome to On the Air with Palantir, a podcast by where we go in-depth on topics related to the business of web design and development. It’s July 2016 and this is episode #6.

This is a special edition really, since this year marks the 20th anniversary of Palantir. It’s hard to fathom considering the internet was still very new in 1996, so there are very few web shops that have been around this long. Palantir started as a development agency, then over time added services such as design and strategy, to become the full, well-rounded, end to end company that it is today.

So we are celebrating our 20th anniversary later this month. I sat down with owners George DeMet and Tiffany Farriss to talk about how Palantir started, how it developed into the company it is today, and where we’re headed.

AM: Hello, Tiffany and George! How are you doing today?

George DeMet [GD]: We’re doing well.

Tiffany Farriss [TF]: Hi, Allison!

AM: Thanks for talking with me, I appreciate it. So we’re going to talk about the 20 years of Palantir. It’s hard to believe, right?

GD: It’s…yeah [laughs]. I’ve never really known anything else, it’s kind of funny.

AM: You’ve never had another job?

GD: That’s not true. I worked for my parents when I was in high school. They ran a disposal and recycling company. So I did have experience growing up driving a garbage truck and managing a recycling center.

TF: This wasn’t what I was going to do, but it is pretty much the only thing I’ve done. Other than having a NASA research grant as an undergrad, this is it.

AM: What were you going to do? I’m curious.

TF: I was going to go to grad school in astrophysics. That was my thing. I really wanted to do astrophysics, and I really liked cosmology in particular. I wanted to study the origins of the universe.

AM: Which we’re kind of doing [laughs]. So let’s have a quick overview of Palantir’s history. How did Palantir begin?

GD: So I actually started Palantir back in the summer of ’96, which was between my sophomore and junior year of college. I had discovered the Web back in the fall of ’94 when I was a freshman, and had really been kind of fascinated by it. It was very new – Netscape was still in beta at that point, and I was just really captivated by this idea of having pretty much anyone in the world being able to publish content that pretty much anyone else anywhere in the world would be able to read and access and view. I thought that was kind of revolutionary and I could see that this was the start of something kind of interesting, and I wanted to be a part of it. And so I started making some web pages, just sort of as a hobby. I made a fan page for ‘2001: A Space Odyssey’ that is still around today, after 22 years. And then I discovered that folks would pay me money to build websites and web pages. So after doing this freelance for a while, I decided it was a good idea to start a company around it.

TF: Because that’s what your family does [laughs].

GD: So that’s probably a little bit of helpful background. Both sides of my family are a couple of generations of people who started and ran family businesses. I mentioned that my parents have a disposal company. My mom’s father had a couple of grocery stores in Leavenworth, Kansas. My dad’s family ran the DeMet candy company, the folks that brought you the chocolate Turtle. So that was really kind of all I knew, right? Working for someone else was really not part of my DNA. So I knew I was going to do something, and when the web came along, it seemed like this was definitely something I wanted to do.

TF: For me, I started on the web around the same time, in 1994. It was kind of an outgrowth of my love of Latin [laughs]. That’s the other thing about me is my love of the classics, particularly Latin, and I was involved in the Junior Classical League in Ohio. I first became the membership director and then the president of the Ohio chapter, and for them I learned how to do HTML. And the web was so new and so exciting, and I had a friend who was at MIT who could give me server space. And this was just so cool that we could be out there and be doing that. So when I met George, when I started at Northwestern, I joined up with him when we were creating a website for our dorm, for Willard Residential College. And we really wanted – our residential college was eclectic, which is probably the best way to talk about it [laughs].

GD: I think the proper way to talk about it was pan-thematic. Most of the other residential colleges had a theme, like arts or sciences or engineering. We were all the things.

TF: We were all the things, we were all the interesting people interested in lots of things. And so we really wanted to do an amazing job creating that website, and that’s really how George and I started working together, in that capacity, and ultimately that’s how Palantir got its second client, or first paying client, depending on how you looked at it [laughs].

GD: That’s right. So one of the things I didn’t know how to do but Tiffany did quite well at the time was to actually go out and find clients. And that’s the skill that Tiffany brought to the table, in addition to her technical skills and managerial skills – really bringing some kind of structure to the enterprise, as it were.

TF: And it all happened in the way we still sell today, in that we’re looking for that good fit. You say, OK, this is what we can do and these are our ideas and this is what we bring to the table. And that’s essentially how we got – when I was a freshman and George was a junior – how two students got the job to do Northwestern’s main university site. It was also the 90s which was a bit of a Wild West [laughs]. But that’s how it happened.

We were at the awards ceremony for the residential college competition, which we won, of course [laughs], and I was talking to one of the judges who happened to be responsible for the web at Northwestern at the time. And she was talking to me about our thought process, and how we approached it, and I was talking about things that are so obvious to everyone now. The three-click rule. Thinking about how users would journey through the path and how you would organize information. And how you apply human-computer interaction theory to the web. But this being early ’97, you know, she said to me, I’m taking classes to learn what you guys already know, can I hire you for $2 an hour as a work-study? And I said, well, I already have a NASA research grant, so, no, but you can contract Palantir. My partner will be in Wisconsin but I can come in for meetings with you. And that’s how we got that contract, so that’s how it all worked out. And that first project was to redo the information technology site, and then in ’97 through ’98 we ended up doing the main Northwestern site.

GD: For the folks at Northwestern, I’ve heard people complain since about the fact that it’s We share a little bit of the blame for that [laughs]. But seriously, nobody calls it NWU. It’s Northwestern. Or maybe NU, but I think that might have been taken.

AM: Well, a pretty auspicious beginning, I would say. Now that you live in Evanston and the office is in Evanston.

GD: Yeah. We never moved [laughs].

TF: Well, this is the thing. I met George my third day at Northwestern, and we’ve been a couple ever since, but we’ve lived within a six-block radius since 1998 [laughs]. Our first off-campus apartment was literally a block over, two blocks away. This has just been where we’ve found a home. Neither of us is from here. I’m from Akron, Ohio, and George is from Wisconsin. We met in the middle and literally stayed.

GD: To be fair, I have some family connections to Chicago. My dad and his family are from Chicago, and so it’s always felt like a second home to me even though I grew up in northern Wisconsin. There’s also a lot more to do here, and it’s a place where even though we are a distributed company and have customers all over the world, it’s a really great place to be.

TF: What I like about it is that irrespective of a physical office, I do consider us to be a firm that’s rooted in Midwest values. And I love that Chicago means business, but it’s business with this ethic. You work hard and you play hard, and you treat people fairly, right? That’s the way that we do things here, and it’s really important to me. And even once we don’t have a physical office or we don’t have headquarters or whatever it is, it’s about the sense of philosophy of place, of being Midwestern. Of being very authentic, being very genuine, and bringing our best selves to what we do.

AM: What would you say, if you can project back 20 years, or 19 or 18 years, the focus was for Palantir the first couple of years? Was the focus just trying to stay afloat, was there a specific direction you were trying to take at the time?

GD: So if you go back in time to the mid-90s and remember what the Web looked like at that point, it was the era of Geocities websites, and everyone was into, like, banners that scrolled across your pages and little animated GIF clip art and animated background patterns, and just really horribly ugly garish sites that people were creating because they could. And one of the things that I really wanted to do at Palantir was to bring more of a design aesthetic to the Web. I really felt that it shouldn’t be too difficult to create websites that were not just functional but were actually easy to use, and didn’t make you want to claw your eyes out when you looked at them. So I thought there was a real opportunity there. Not just to be able to do business, but also to help make the Web a better place. And that was very much what we wanted to do, certainly for the first couple of years, and even beyond as we started partnering with other folks. I think making the Web look better and work better for people was really key in those first couple of years.

TF: And for me, I think – I agree with everything that George said, but I also felt very strongly about how the information was organized and presented. At the time it was a lot of brochure-ware. People were essentially trying to put these very linear experiences up on the Web. Now we call it ‘content strategy’ but at the time it was ‘information architecture’, and I really loved to think about the way to organize information in a way that made sense to someone who had no familiarity. It wasn’t about creating this highly linear journey for them, it was about – I saw the promise as being able to present information, to allow people to get what they wanted, but still to also come away with the message you wanted them to have. I thought that was such an interesting challenge, to be able to allow people to take control of how they gathered information, to really put the control back in their hands, but still to have it be that kind of alignment where you as the content provider were getting your message through, right? And that’s still a lot of what underpins our work today, is really this kind of ‘choose your own adventure’. And that’s where the name really comes from and why it comes into play.

GD: So the name is something I came up with. It represents this idea of interconnectedness. The Palantiri are these communicators that in a fantasy realm are interconnected with each other, so you can look in one and communicate with anyone else who has a Palantir. The dominant metaphor at the time when Palantir started was the information superhighway, and I felt that metaphor was really flawed because it implied this kind of linearity, right? But the Web isn’t like that. The Web is this very decentralized interconnected place, and it really feels more and it actually is this network of interconnected communication, of nodes, really.

TF: And it’s interconnected not just in terms of people, which it certainly is and always has been since its beginning, but it’s also in terms of content. What I love and what I find so fascinating and interesting is the notion that you don’t have to encapsulate all of the knowledge – you can just link to it, right? So you can tell a story and you can pull together these varied threads, and braid it together into a narrative in such an interesting way. And anybody can do that. It’s so accessible that it’s really broken down some of those traditional barriers that essentially gated who was able to define the narrative. So any person now can define that narrative and string it together. This is why a lot more of our work recently has dealt with APIs and what we can do to bring pieces of content from different systems together. And ultimately it’s why I’m so passionate about Drupal, because the ability to weave different pieces of content together but allow them to remain authoritative external sources is so exciting.

AM: So it seems that, 20 years later, what you had outlined for yourselves back then still stands today.

GD: Absolutely, no question. We’re still facing some of the same sorts of challenges. They’re very different in nature, but fundamentally it’s a question of enabling people to be able to access information, or to create information, or to share information in a way that’s findable, that’s usable, that’s discoverable. That’s what we started out trying to do, and that’s what we’re still trying to do today.

TF: I have this very Teutonic brain, I like things to be very efficient. So for me the notion that I could weave these narratives together but allow there to be single authoritative sources of information, I don’t have to duplicate it – it’s very efficient, it’s so compelling to me. And this is where I think you see a lot of enterprises getting too narrow, with their notion of the omnichannel strategies – where you want there to be a single source but you need to kind of customize what that experience looks like. And you really get – by being so efficient with presenting that information and where you’re sourcing the information, you get to focus your efforts on how you differentiate it in different channels and different contexts, and have other people mix and potentially remix your information. That’s what’s so exciting about where we are today, but it’s not that different than in ’96. We were really trying to get authoritative sources, that was the key, to kind of have those sources be out there and have them be integrated together.

AM: So you would say that Palantir’s core values and mission really haven’t changed at all, or maybe just better definition.

GD: I would agree with that. What we’re trying to do, how we’re trying to do it, really hasn’t changed. What has changed is that we’ve talked about it, we’ve articulated it more publicly. It’s not just locked in our brains [laughs].

TF: Right, it’s those notions of assumptions so deep that you’re not even aware of them. For so many of the early years, we just knew. And because we were a smaller company and everybody worked with George and I on a daily basis, you just kind of felt it. You didn’t know it. I couldn’t articulate it very well, and it’s taken us several tries to be able to get it to the point where we feel confident saying, yes, this is it. Because words matter so much, and there’s such precision when I use language that I’m constantly trying to make sure, is this the right word to use, is this really capturing that feeling that’s so deep in our culture that I want other people to be able to grasp onto it.

Because we do have this growing firm, and our folks here today – George and I are clearly the longest-standing employees of Palantir, but we have folks who start in a week. So how do they get a sense of the history? So it’s this notion that we have to really have those core values, as guiding principles, articulated so that, without knowing the lore and history of Palantir, they can apply it going forward. It’s really been an interesting challenge and one that George and I have been focused on for probably the last 18 months, is realizing that all that shared history has to be able to be communicated, has to be able to be transferred. And that’s been a really exciting part of the challenge.

GD: And it’s not just communicated, it’s also contextualized. That’s the really fun part for me.

AM: It’s very hard to define your own selves, too. It’s definitely tough work.

GD: It is. But I think it’s essential. I think it’s something that has been kind of a hallmark of who we are. It’s really this constantly asking ourselves and trying to be as self-aware as possible about who we are and what we do and why we do it.

TF: And also what we don’t do, right? I think that as we look at the growth over the last 10 years, it’s really easy to think that we were something we weren’t. We were never a start-up. We’re celebrating our 20th year so by definition we can’t be a start-up, and even in the past 10 years we weren’t a start-up. But it might have felt that way, or it might have looked that way. And so it’s on us, it’s our responsibility, to make sure that people understand – both our clients and our friends and our colleagues – that we are approaching this with very much a fundamental family business mentality. Really old-school principles. You don’t spend money you don’t have, you treat people fairly. This kind of notion that you’re always building, that every decision you constantly make has to be adding up to something. And I think that’s been – we certainly have friends who made other choices with their companies, whether they consider themselves a tech company or a start-up and they go after VC. We’re just not that. And we totally admire them and wish them well with what they’re doing. We’re doing something a little bit different over here. So in order for folks to understand that, we have to talk about it. We have to say, you know, we don’t spend other people’s money, we don’t spend money we don’t have.

It’s been such an interesting journey, particularly for me not coming from a family business background, to understand really what that means and why that applies and to be really proud of it. I really think that’s the compelling thing here. Because at the end of the day, I’ve always believed that what you do outside of work makes you better when you are at work. And you have to have time and space in your life for that. And I believed that before I had a family, and I certainly believe it to be true now. How I live it, how I articulate it, is very different. And I think that’s right, that’s appropriate, to be able to evolve with you and to be able to change with you. And that’s the kind of company that we’ve built.

AM: Well, one of the things I’ve noticed specifically about Palantir is how involved you’ve gotten in several communities. One of the reasons that I actually knew Palantir for years before working here was your commitment to design, which George mentioned was an early interest, and you did partner with design firms in Chicago when at the time you didn’t have an in-house design department, you were strictly development-only. So you were prescient and smart enough to know that you should partner with some very good design firms in the city, and there is a very strong design community here. And so you actually joined the American Institute of Graphic Arts board at one point, to become, I think, the Web liaison.

TF: Electronic Media Chair, yes. I was lucky enough to be Electronic Media Chair for AIGA Chicago, and that came after several years of working with and partnering with those design firms. And that was such an invaluable time in Palantir’s history. Chicago does have such a very storied and internationally respected design community, and the opportunity to work in such an early stage in my career, and in Palantir’s lifespan, with some of the best – looking back on it, it was unbelievable. To be able to learn and work so closely with really, really smart designers as they were making that transition from being exclusively print designers to thinking about interactive design and Web design – it was such a neat time for all of us. We were bringing this very digital sensibility with us and they were bringing expectations of typography and color fidelity. And those were things that were really difficult in that early Web. It was really amazing. And that all came out of our early work at Northwestern. We originally started out partnering with the information technology department over there, and through that work we advocated that the university relations people be included in that conversation. Because we felt that there was a role for branding and photography, and just design standards as part of the work we were doing for the Northwestern home page. And through that we ended up learning how to work with traditional print designers.

And our business has always been built on this word of mouth, on reputation. And so through that experience we ended up getting connected into the Chicago design community, and passed from firm to firm to firm, and I see that being appointed to the board was really the outcome from that, after the several years we’d been working with and partnering with design firms, from 2001 – I think it was 2001 when I became Electronic Media Chair, until 2008 – we had been working for six or seven years. But I still reflect on those experiences and what I learned from working with those folks, just in terms of how to relate to clients and how to really be a consultant. It was an amazing opportunity, it was really great. I’m really grateful for it.

AM: And around the same time, around 2008-ish, was when you started to get involved heavily in the Drupal community as well.

GD: That’s right.

AM: So a pretty pivotal year there [laughs].

GD: Well, the Drupal decision we actually made in 2007. We had started working with Drupal in 2006, but to lay a little bit of background, we’ve always worked primarily with open source technologies – open source software, free software, from the very beginning. The LAMP stack, Linux, Apache, MySQL, PHP, and used those technologies. And I had always been interested in getting a little more involved with open source on the content management side. We did a little bit of looking into that around 2001, when some of the first generation open source CMSs started to come on the scene, and none of them were really never mature enough at that point. And at that point we actually thought we could probably do our own, just as well if not better. So we had our own CMS for a while – it was called the Community Platform and we did four major versions of it, each of which was pretty much a complete rewrite. Was it just three?

TF: We were thinking about doing a fourth.

GD: Right, right. And that was a really interesting learning experience for us, because when you are responsible for creating your own product that you are then in turn using for customer projects, you have to really be careful. Because there’s a huge temptation to modify it or tweak it or change it every single time. So what we actually found was that we didn’t have one CMS, we had however many dozen CMSs, each of which was a bespoke version for that particular client, because we had had to make some sort of tweak for the business needs of that customer. Which was great in terms of the short-term customer need, right? Because we could very quickly and inexpensively roll out a site for a customer, get it up very quickly, but when it came time to expand that site or support that site or make that site do something different, it was incredibly difficult. So that was one of the big issues that we were running into. We had worked with some other proprietary platforms – there was a product that was being used by a lot of higher education institutions we were working with in the early 2000s. It definitely had its challenges, but it was something our customers were using and it worked well for a lot of our customers. And ultimately the company ended up deciding to end-of-life that product, actually without telling any of their customers [laughs]. We had a little inside knowledge on that, and Tiffany actually announced it up on stage at South by Southwest, I think this was 2007.

TF: 2008.

GD: 2008. And it was really kind of interesting seeing everyone flee the room when you made that announcement.

TF: The 20 people.

GD: The 20 people, yes [laughs]. I mean, you know, it was a pretty big session. So at that point, things were kind of – we realized we really needed to get involved with, you know, something that was going to be more widely supported by a wider community, and that also wasn’t going to be tied to the commercial whims of one particular company. And so I’m actually going to let you tell the story of how we started working with Drupal.

TF: It happened over several years, really. In 2006, Robert Petrick, who’s one of those amazing Chicago designers that we were lucky enough to work with, he brought us in on a project for Washington University in St. Louis. And the project was a little unusual, because it wasn’t an implementation project. It was going to be an implementation project, but first it started with a consulting project, where they wanted us to look at the available landscape of content management solutions, but both bespoke – our Community Platform was on the table for consideration – and open source projects as well as proprietary. And I helped them make the decision, and open source was absolutely the right choice for them. Again, we narrowed it down – should it be Drupal, should it be Joomla, and there were a couple of other options they were considering at the time. And for them Drupal was the right choice. So we built out that first site for WSTL in Drupal 4.6, and it was a little bit frustrating. But 4.7 came out actually before the site launched, and we immediately upgraded it to 4.7. We had looked at 4.6 before and not used it, because we couldn’t do the things we needed to visually. We were working with a lot of the design firms, and we couldn’t tell them, oh, the technology choice we’ve made won’t allow us to present the interface visually the way you want it to be done. That was why we had our own community platform, and in 4.6 we felt that was still very much the case, we were very much limited by that theming layer. Then 4.7 ended up being the right choice for Washington University in St. Louis, and we built out the site there, and it was still a bit frustrating but we achieved the level of fidelity we wanted. And as we were wrapping up that project and getting ready to launch it, Drupal 5 came out. And without launching the 4.7 version we ended up going to Drupal 5 right away. And that was when our team said, oh, this is different, and we can do everything that is being asked of us visually, everything we want to do visually. And by the way the security team that Drupal has is larger than our entire firm.

So it was really in early 2007, in February 2007, when we were faced with rewriting our community platform from version 3 to version 4, it was going to be a complete rewrite – I just looked at George and said, I think we need to deprecate our own CMS in favor of Drupal. I think we need to put our efforts in that direction. So the next month we actually sent George and one of our colleagues at the time, Larry Garfield, who’s known as Crell in the Drupal community, we sent them both out to Sunnyvale where Drupal was having a DrupalCon, to learn more about it. And George came back and said, I think this is a community you’d really like. And you could really get involved in this. Ah, I don’t know, let’s just start with where we’re at right now. And then you do fast forward, that year of 2007 was when we did a lot of our first projects. We got all of our clients off our own community platform, and any new project we’d start doing in Drupal.

AM: How were they when you suggested getting them off the existing platform and getting them onto Drupal? Were they receptive to that, or were they hesitant…?

TF: We did it gradually, as people needed new enhancements or new versions of their sites. At the time, none of the sites we were working on had particularly long life spans, right? And we ended up having to support the community platform for several years thereafter. So it was really when someone came to us for new work, it was, oh, here’s Drupal and we think you should move here for the following reasons. We would lay it out, but we weren’t going to do any new enhancements to it, and we told them very clearly, we’re not in active development on the community platform any more.

GD: One distinction that’s important to make, I think, is that with our own product, the Community Platform, it wasn’t an open source product, but we did have our customers have the right to modify the source code themselves. They just didn’t have the right to redistribute those changes. So if customers wanted to take on that responsibility of updating or maintaining the site themselves, they were certainly able to do that, or we gave them the option of moving to Drupal.

TF: Right. So really through 2007 and into 2008 – 2008 is really where we got involved in the Drupal community per se. And that’s when I went out to Boston, and I said, oh, this is a community I will love. This is something that – the ethos of it, getting to meet Dries and Angie Byron and Moshe Weitzman, all the early and very influential Drupal developers, and just how welcoming and how open they all were. And what we were able to build with Drupal was just so much more than we would be able to build if we were responsible for the whole stack. It just started to fall into place, it started to make sense that we could do more for our clients. And that’s ultimately what’s always driven us. We’re trying to add value. We’re trying to say, because the clients we work with have limited resources and are always under constraints, what’s the most we can do for them? How much can we accomplish, how much value can we give back to them? How much easier can we make their lives by the choices that we make all along the project? And Drupal was one of the ones that made a lot of sense for them. It had roughly the same implementation cost as any other proprietary or custom solution, but in terms of the long term, it was much less expensive. Because you didn’t have the long-term licensing fees, you had the community patching issues – so sometimes a client would say, oh, I’m noticing this bug on the site, and we’d say, oh, actually that’s a module that’s been patched in, we can patch that for you. It really opened it up and allowed us to focus.

So all these kind of pivotal points that you’ve noted in Palantir’s history, they come around our ability to focus. Right? So in 2001 when we really started partnering in earnest with design firms, it allowed us to focus and really hone our craft, and understand how to do content strategy and how to architect solid technical solutions. And then again in 2008, when we focused in on Drupal it allowed us to realize, okay, here’s how – only build what you absolutely need to build. That really allowed us to do more with our client budgets, and again, I would say 2016 is another one of those pivotal years for us, when we realized how to focus in and how to really get to the nugget of the business problem that needs to be solved. We have the opportunity now to influence businesses and the success of those businesses, and organizations as well since we do so much work with non-profits and higher ed in particular, and really how to solve core problems that aren’t technology problems. They’re problems that reach across the organization at every level, and so the fact that we’re able to focus in on it from that perspective, with that lens, I see that as another transformational moment for Palantir.

AM: It seems like you had some very pivotal choices that you made, in 2001 to 2008 in particular - partnering with design firms, choosing open source and eventually choosing Drupal – and that you were sort of on the forefront when the mid-2000s hit. That was when it seems to me, from my perspective, that you were a very big fish in a tiny pond at that time. You had this incredible design aesthetic and appreciation, you knew how to work with design firms at that point – you weren’t doing in-house design yet – and you were one of the few firms who had really embraced Drupal in particular. And that community was exploding, and I’m not sure if you could see that community was going to explode, if you were able to predict that.

GD: It was pretty apparent when I went to Sunnyvale in early 2007. That was a very small conference, it was maybe a couple of hundred people, and not all of them were Drupal people. But it was really, really clear just from the conversations that were happening and the folks that were there that Drupal was on the verge of becoming a big deal. And it was really funny, because I think the first couple of years that we started working with Drupal, we would go to industry conferences like higher ed conferences or museum conferences, and people would be like, oh, what do you do, and we’d say, we work with Drupal. And people would be, Drupal, what’s that? And then a couple of years later, we would go to the same conferences, and people would literally come up to me, like, I hear you guys are experts in Drupal and I need a Drupal expert [laughs]. So there really was a huge shift, I think, between 2008 and 2011, when Drupal went from being kind of this niche open source project that very few people had heard of that powers some of the biggest and most ambitious sites on the Web.

TF: And I think a lot of that has to do with the ecosystem that was built up around Drupal. Not just Acquia but especially Acquia, which is the firm that Dries Buytaert founded and is CTO of, that really brought a lot of visibility to Drupal particularly around hosting and 24/7 support. I think that was a really important moment for Drupal. But I think what was happening before then as well, not just with firms like Palantir but the work that Phase2 was doing in the government sector – there are a lot of firms both in the US and Europe that were doing this very ambitious very large-scale work. You had Examiner really pushing the development of Drupal 7, and then eventually the White House goes to Drupal, and everything that was happening with Warner Brothers and SonyBMG putting all their artists on Drupal – Drupal became this kind of de facto go-to. When you had a project that was, as George said, ambitious – it didn’t necessarily have to be large, sometimes they were technically complicated and involved a lot of integrations between different kinds of data sources. That was the kind of work that we did, both for higher ed and for museums, where we were combining, say, digital asset management systems with content management systems with active directory or LDAP-based user solutions. Any kind of complexity at that level, Drupal’s so good at tying those systems together. Or if you wanted to go headless, right now Drupal’s very good if you want to have, you know, no front end to your data source. Drupal just knows how to connect people, how to connect things, and it gives you such a good basis for what you’re trying to do, or trying to replicate. If you need a thousand sites, right, this is again what Pfizer does, and they’ve got such huge regulatory concerns that Drupal, you know, was just always there.

And those of us in the, I would say, the second wave of Drupal – Palantir’s not a first wave Drupal shop, we really did start to come on line with Drupal 6, and we were essentially writing for those pieces that our clients need. So again this is that ethos that we have, where we’re going to find that win-win solution. And what we did early on, and in particular when we made our name with Drupal 7 where we created Workbench, it was because this was a need that our clients had, and multiple clients had that need at the exact same time. It was a space that Drupal just wasn’t solving, and it was something that we had the capacity, we had the expertise in-house to be able to write. So we were able to combine pooled budgets from some of the smaller non-profit clients that we had, combine them together and get that better solution than they would be able to afford on their own, and make Drupal better – those are those niches that we’re constantly looking for. Okay, where can we add the most value here, where’s that problem that we can pull the resources together to solve – whether it’s people or time or money.

AM: Well, I think one of the direct results of – maybe Palantir wasn’t a first adopter, but pretty early, still, and the creation of Workbench which has proven to be very popular, and going back to the fact that those choices led Palantir to be a pretty big fish in a small pond for a long time – one of the things that I think is amazing about Palantir is that for 17 years, I think you told me, you never had to do any marketing.

GD: That’s right. No outbound marketing.

AM: That’s a dream, right? [laughs] To never have to look, the referrals came so naturally. But then, 17 years in, as Drupal became more ubiquitous and more people were adopting it and more people were recognizing the design abilities of it and the flexibility on the front end, marketing all of a sudden was needed [laughs] because there was more competition. So how would you say the landscape has changed? I’m going to guess that was a pivotal moment too, just how that landscape changed.

GD: Well, I don’t know that it’s a pivotal moment – I think it’s been a general trend we’ve been seeing over the past few years. And fundamentally I think if you – we talked about focusing, and that’s important, but if you narrow your focus too much and you find yourself in too much of a niche and people associate you with a specific technology or a specific type of client, that’s not a great situation to be in. And I wouldn’t actually describe us so much as a Drupal shop, we’re a full service boutique firm that helps customers be successful on the Web. And fundamentally the tools we use to accomplish that – what’s important to us is helping our customers make the right choices, collaborating with our customers, being able to help them to achieve success. Drupal is and historically has been a really great way to do that for an awful lot of our customers. But at the end of the day, it’s not about being the biggest or the best or the most well-known Drupal shop. It’s about being a firm that can help achieve success for our customers, in a really smart way. And because we were so closely associated with Drupal, that’s something we didn’t talk about as much. But we have started talking about it a lot more in the last few years. So if that’s marketing, sure [laughs].

TF: Well, I think it is. Early on, in those days when we were partnering, it was, oh, you’re the people who know tech who know how to talk to designers. So we want to work with you.

AM: Which is a valuable skill [laughs].

TF: Absolutely. And we keep it with us, we still have it today. But at the time, what we were doing was problem solving. We were hearing what they wanted, what their clients wanted, and how we solved it, right? But then you fast-forward to Drupal, and then we had this really great run where it was like, Palantir! You know Drupal! We want to work with you! But at the end of the day we did the same thing. You come in, you have a problem to solve. They picked us for different reasons and they were pleased with the outcomes, and that’s how we ended up getting those referrals and that engine. But as Drupal matured and as Palantir matured, and, quite honestly, as the Web matured as a channel in its own right, not kind of as ancillary to the traditional channels that businesses and organizations relied on – as it became co-equal and even dominant, the expectations of what people needed from the Web started to go up. So I think that the notion that, oh, you’re good at this tech thing was no longer going to be compelling, it was kind of a given. Oh, we’re going to bring you in as a partner, we assume that you have technical expertise, but we need to know that you have the strategic expertise to help us make those good decisions. And we need to know that you are going to work with us to help us build our internal capacity around this. Because the Web has gone beyond something that you would just give to, you know, your neighbor’s kid who knew how to do HTML, to, you know, the core of many businesses. And right now we’re in this era where even the oldest and most established businesses are going through digital transformation. It is reshaping how everyone works right now. So the expectations, and rightly so, have changed. They’ve increased, And Palantir has had the luxury of all of this time to mature and to hone our craft, and we are still excellent problem-solvers. That approach, combined with all the expertise we’ve built up over the last 20 years, makes us a really great partner.

AM: So now it’s July 2016, celebrating the 20th anniversary, and we’re having a company retreat – we’re shutting down everything for a week to bring all the employees, one from as far as South Africa, to Chicago so we can all get together and celebrate and – there’s going to be some work too, internally, but there’s going to be a lot of celebrating. So my final question: what would you like to see for the next five years, moving forward, or two years, what would you say?

GD: [laughs]

AM: Is it overwhelming, is it too much…?

GD: No, no – you know, actually a couple of years ago we set out a couple of very high-level goals for the company, and we’re kind of in the middle of the process of that, of working toward those goals. We refined them a little bit at the beginning of this year, but they’re still fundamentally the same. And it’s about helping our clients achieve success on all of our projects, that’s number one. Number two, continuously learning, sharing and applying new knowledge, and this is one I’m really interested in having us focus a lot more on in the coming years. That this learning and applying new knowledge is really not just about technical skill or expertise, but it’s really about new ways of understanding people’s problems and looking at people’s problems in new and different ways. And developing our skills internally in terms of being able to understand and address those issues and questions and concerns, and the goals that our customers have. And then of course continuing to be a sustainable well-run organization with healthy finances and a happy staff. Those are the three things we’re working on. I think when we get together here for our on-site we are going to really talk a lot about how we’re going to do those things, and figure out and talk about what we’re going to do. We’ve spent a fair amount of time over the past year talking about what we have done – you know, how we are where we are today – and I think it’s time to start looking to the future.

TF: Building on what George said, I think learning really is the key. It’s about taking what we learn on every project and elevating it to the level of organizational learning, and doing the same thing for our clients. We have a long track record of collaboration and we have clients who embed with us and who we help level up and we make kind of essential parts of our projects. And that’s fabulous, and that’s a huge service for capacity building for our clients. And I think the opportunity I see is being able to take that and transform the organizations as well, so that they also have an organizational learning moment. So for me, I’m really focused on the notion of making sure that we’re getting the most out of every opportunity, out of every decision, and understanding why things worked or why things didn’t work, and how we make it better. And it’s this notion of continuous improvement, and really making that a core part of our service. I see that as kind of the biggest change. Because as the industry and the Web kind of matures, and continues to mature, I think we’re getting to this point where we’re going to see fewer and fewer exponential leaps, and I think it’s going to start to plateau off. And so the notion that you kind of create and institutionalize incremental learning is really going to be key for us and for our clients. So that’s what I want to focus on – how we help them continuously improve, not only in their website and their Web presence and their infrastructure and their digital strategy, but how they can continue to incrementally improve their teams and their organizations to be able to take advantage of and recognize opportunities when they come up.

AM: And cake. There will be cake.

GD: I hope there will be cake. Who’s in charge of the cake? I’m not in charge of the cake! [laughs].

AM: Well, thank you very much. Looking forward to our retreat, and looking forward to the next five.

GD: Absolutely.

TF: The next 20! [laughs]

AM: Why stop at five? The next 20! [laughs]

AM: Thank you so much for listening.  I have to say, after three years of being with Palantir myself, and after having worked with them for several years prior to that, I’m thankful that I get to go to work every day with really, really smart and thoughtful people who are creating great work and toiling every day to make the Web a better place. So - happy anniversary, Palantir!

If you want to hear more episodes of On the Air with Palantir, make sure to subscribe on our website at There you can also read our blog and see our work! Each of these episodes is also available on iTunes. And of course you can also follow us on twitter at @palantir. Thanks for listening!


The Secret Sauce podcast, Ep. 24: Sync Your Sales and Marketing

July 5, 2016

Sales and marketing tactics can complement each other well when used collaboratively. Learn how Palantir intertwines the two disciplines to better understand (and reach) clients.


Allison Manley [AM]: Hello and welcome to The Secret Sauce, brought to you by This is a short podcast where we offer a quick tip on some small thing you can do to help your business run better.

I’m Allison Manley, an Account Manager at Palantir, and today’s advice comes from Alex Brandt, who talks about how to combine sales and marketing.

Alex Brandt [AB]: A lot of people think of sales and marketing as two separate entities, but the truth is they can both benefit greatly from working together. At Palantir, our sales and marketing efforts are strongly intertwined, and we have found this approach to be extremely effective.

For starters, sales helps marketing by informing content.

Most often, clients have their first direct interaction with a company by communicating with the sales team. That means the sales team is hearing firsthand what new clients are looking for, what their goals are, what pain points they are dealing with, and ultimately what they think will make their project become a success.

The sales team also has a good view into what kind of clients are reaching out. For instance, we have seen a shift in what roles are involved in managing a website redesign. While we used to interact with mainly Directors of IT and other similar technical roles, we now see a lot of marketing teams heading up these kind of projects.

This valuable information helps inform what kind of content we should be producing. If we are speaking with more marketing folks than technical, and they are coming to us with new problems and goals, the kinds of resources we are providing for our clients should reflect that. And if this trend shifts again, our sales team will be the first to let us know so we can pivot and adjust.

In turn, marketing helps sales by providing a gateway for conversation.

Now that the sales team has helped clue us in on what kind of content we should be producing, our marketing team gets to step in and create compelling resources that make people want to work with us. These resources get distributed across different channels and open a path to conversation with sign-up forms for free consultations, newsletters, and webinars.

But most importantly, an open and collaborative approach gives all team members the context to keep messaging consistent.

Whether it is coming from a blog post, an introductory phone call, or a presentation at a conference, the message a brand is communicating needs to be consistent and in line with what your clients are searching for. Clients want to know that they are being heard and understood, and by keeping a fluid conversation between sales and marketing, this can be accomplished.

AM: Thanks Alex! For more business tips, or more information about Palantir, please visit our website at, or follow us on Twitter at @palantir. Have a great day everyone!


The Secret Sauce podcast, Ep. 23: Choosing Fonts for the Web

June 28, 2016

Typography is a huge and critical component of the Web. So what do you need to know about web fonts for your site? Designer Michellanne Li goes into the details.


AM: Hi again everyone, and welcome to The Secret Sauce, a short podcast by, that offers a quick piece of advice to help your business run smoother.

I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from one of our designers Michellanne Li, who is going to talk about web fonts.

ML: Hello, my name is Michellanne, and I am a designer here at Palantir. Today, I am going to talk to you about web fonts: what are they, and why do you need them? How do you select fonts and implement them on your website?

In the early days of the internet, browsers could only render a handful of typefaces, 5 of which became commonly used. Over time, however, browsers and font files have developed so that we literally have thousands of options when we look to select a typeface for a website.

But, first of all what exactly is a web font? According to “A webfont is a font file downloaded from a Web server and used by the browser to render HTML text.” The desktop fonts that you use in Word or Photoshop are specifically encoded to be rendered by a computer. Desktop fonts come in the following file types: TrueType, PostScript, and OpenType. However, web fonts are created to be read by browsers. Web fonts come in: TrueType, WOFF, EOT, and SVG.

So, from a technical standpoint, you need web fonts if you are building a website because they are specifically encoded for the web. But from a design standpoint, good web fonts have features that make them particularly suited to being read on a screen. For instance, they may have wider letter spacing, heavier strokes, or taller x-heights (which are the relative heights of the lower case characters). All of these result in greater readability on a screen. Users don’t spend a lot of time on each web page, so making smart design decisions is critical in ensuring that your content reaches it audience.

According to the User Experience experts at Nielson Norman Group, “the first 10 seconds of the page visit are critical for users' decision to stay or leave. The probability of leaving is very high during these first few seconds because users are extremely skeptical, having suffered countless poorly designed Web pages in the past.”

Now that we know what web fonts are and why you need them, let’s talk about the financial and technical considerations behind selecting the right fonts. The following are some guidelines to keep in mind:

Free fonts are great! . . . sort of. In 2010, Google launched Google fonts, making hundreds of web fonts available to the public free of charge. To do this, Google has collaborated with designers in exchange for a flat fee and the promise of exposure. Google fonts can be a great option if you are on a really tight budget. However, the following are risks to consider:

  1. Unfortunately, Google fonts are not held to any external standards, both from an aesthetic and technical standpoint. Before choosing one, it’s wise to verify if it works in all major browsers.

  2. Unlike commercial fonts, many Google fonts do not come in a range of weights or styles, such as italics.

  3. Due to the Chinese government’s censorship of Google, Google fonts do not work in China. If you have an audience in China, this is important. Websites with Google fonts not only load slowly, they may appear “broken.” Although workarounds exist, they all come down to finding a different source for fonts. Some of the latest sources are Chinese services that host Google’s fonts on their own servers. Although this probably is not illegal, I would not recommend that clients use a fonts platform that did not pay for its fonts. It is, to say the least, poor form.

  4. Free fonts, including but not limited to Google fonts, get enormous mileage both in print and on the web. When it comes to simple classic typefaces, that’s not a bad thing. They are like the little black dresses of typography. But, if you’re looking for a high impact display font to differentiate your website, selecting the same free font that everyone else has already used to the point of exhaustion will have the opposite effect.

All of this being said, Google fonts has some real gems and is a solid, budget-friendly option. So, why bother shelling out money for a commercial font? You should purchase a commercial font when the following are your priorities:

  1. Quality: Commercial fonts are held to high technical and aesthetic standards. The best typeface foundries put an incredible amount of thought and detail into their work and can answer questions about browser compatibility, usage scenarios, and the history behind each typeface.

  2. Brand consistency: If you have an existing brand that includes typefaces for print materials, it’s worth it to purchase the corresponding web fonts. In the event that you are just starting to establish your brand, now is a good time to ask if the typefaces you like have print and web equivalents and to determine how well these potential typefaces work in both kinds of media.

When purchasing a commercial font, it is important to read the licensing agreement. Font designers and retailers place constraints on the scope of a font’s usage in order to protect the value of their product.

So, at this point, you’ve picked your fonts, and you’re ready to start using them on your website. How does that work? One option is to use a hosting service for your fonts, which means that your font files will reside on the server of the company from which you obtained them, and your website will load those files. For commercial fonts, hosting is a subscription-based service. The advantages of this are:

  1. Implementing the fonts on your website is as easy as adding a single line of code.

  2. Web fonts get updated as the internet changes and grows. With a hosting service, your provider can push the latest versions of the font files to the cloud server, and they will be automatically loaded onto your website.

  3. You don’t need to keep track of the font files.

  4. Hosting services offer some great bargains. For instance, Typekit is a hosting service that is bundled into the Adobe Creative Cloud package. For no additional cost, this includes unlimited web font usage for up to 500,000 page views. All of that being said, Typekit isn’t really a bargain if you don’t need Adobe Creative Cloud to begin with.

Self-hosting is another option. Self-hosting means that the font files exist on your server. The main advantage of self-hosting is the ability to subset fonts. This means editing the files to remove unneeded characters. Subsetting results in smaller files sizes, speeding up the load time of your website.

In summation, web fonts are an important component in creating a website because they are specifically designed and encoded for the web. In selecting fonts, both financial and technical considerations should be taken into account. Once you’ve determined your fonts, you can choose to use a hosting service or to self-host.

Even when we’re not conscious of it, typography is a huge part of the web. I hope this talk will contribute to making the web a more beautiful and user-friendly place!

AM: Thanks for listening to this week’s Secret Sauce! For more great knowledge, visit our website at, or follow us on twitter at @palantir. Have a great day!


Selecting the Right Image Type to Improve Site Performance

June 21, 2016

It’s hard to know which type of image will best help you optimize your site’s performance. Front-end Developer Patrick Weston breaks down four different image types and assesses the function and benefits of each kind.


Allison Manley [AM]: Hi and welcome back to this week’s Secret Sauce, a short podcast by that offers a quick tip on some small thing you can do to help your business run a little bit better.

I’m Allison Manley, an Account Manager, and today’s advice comes from front-end developer Patrick Weston, who has some thoughts about dealing with images on the web.

Patrick Weston [PW]: Hi, I’m Patrick, and I’m going to be talking about images on the web.

The web is really progressing forward and evolving, and as developers we tend to take data and speed for granted. We normally work at businesses and offices with really fast broadband connections, but that might not always be the case for all users. Responsive web design has really focused on mobile first, and a lot of times these mobile users are data capped or have their data limited. And they can also be in remote locations on slow connections.

Images are often the largest asset on web pages. So if you make improvements with images, you can really make large improvements with your site speed and performance.

I’m going to talk about different types of images, when to use which, and some general tips for improving your site with regard to images.

First, I’m going to cover two different types of categories. There are:

  • Lossless vs. lossy compression

    • Lossless as the name implies, is no loss of data. So these are images where the source feed is the exact same as the outcome.

    • But lossy compression allows you to lose some quality at the sake of file size.

  • There are also vector graphics vs. raster graphics

    • Vector graphics are defined mathematically. For example, a line starts here, and ends here 10 pixels over.

    • But Raster is defined pixel by pixel, so you can think of it as kind of a 2D grid with different colors at each pixel.

So now I’m going to talk about the different types of images that there are. There are four main types:

  • PNGs

  • JPEGs

  • Gifs

  • and SVGs

I’m going to go through each one and kind of talk about their strengths and weaknesses, and then I’ll recap about when to use each type.

PNGs are the first type I’m going to talk about. They are a lossless file format, so you don’t lose any quality. And they are also raster, so they are defined pixel by pixel. But the benefit with PNGs is that they have what’s called an alpha channel, so this allows for transparency. If you’re using transparency on the web, it’s likely a PNG. And this alpha channel is a scale of transparency, so it can have different values of how transparent the image actually is.

The next are JPEGs. These are kind of the workhorse. This is one of the most common file formats, and it’s a lossy file format, so you can have some loss of quality, but also save image size at the same time. They are raster, so they have a 2D grid of pixels, and they don’t have an alpha channel, so there’s no transparency.

The next type are GIFs. They are also lossless and raster. They do support transparency, but it’s  kind of an on/off switch, so the pixel is either transparent, or not transparent. So you do lose some quality here with the transparency. But the main thing that makes them famous on the web is that they support animation. So if you’re looking for kind of a simple animation, GIFs are a good way to go.

Last you have kind of a newer file format that’s beginning to be more popular on the web , and that’s SVGs. They are vector graphics, so they are defined mathematically. You have shapes and sizes, different line widths, thicknesses, colors . . . they’re really versatile.

These four file formats are kind of confusing, and there are different approaches to when you want to use each of them. So the real key is to kind of figure out what image is best for you.

If you need any sort of animation, GIF is the only option. It’s the only one that provides animation without using a video format.

If you need any sort of transparency, PNG is probably your best bet because it gives you that alpha channel for transparency that is a nice scale rather than just an on/off like GIF provides.

But if you have an image that’s a photo or a scene, a JPEG is probably your best choice. And JPEGs are probably your best choice just by default (unless you don’t want to lose image quality, in which case a PNG is also a great choice). The great thing about JPEGs is that you can set the quality.

If you have something that needs to scale well . . . a logo, or something with simple shapes and colors . . . then go with an SVG, because they can have really small file sizes.

Other alternatives that you can use include CSS. A lot of times you can do gradients or background images, and you can avoid images all together. Or if you have a logo you can use text or a web font.

And there are also some great approaches that are starting to come out, and become more popular, for responsive images. One is called  “Srcset.” It allows you to define different images depending on the width of your browser. There’s also the picture element. And Drupal also has a great responsive image module that’s new in Drupal 8. You set up different images sizes and styles, and then tell Drupal when to apply each.

But all of these really depend on having a really good source image to begin with. You can do all sorts of responsive tricks and things. But if your source image isn’t the right type and isn’t optimized, it’s not going to be a good result.

There are lots of types of images out there. But with a little thought, and with the help of some new best practices and automation (like Drupal’s new responsive image module), you can create a great, fast-loading site for all users regardless of screen size or internet speed.

AM: Thank you Patrick. That’s it for this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at Have a great one.

Helpful links

Image types and when to use them:

Configuring Drupal's new responsive image module:


How to Write a Better RFP

June 14, 2016
Writing a Request for Proposal (or RFP, for short) is no easy task. You want it to be as detailed as possible, as to ensure you get the right kind of proposal from the right kind of vendor, but general enough since you're not entirely sure what you need – and the expertise of the vendor will help articulate some of that, ironically.
So how can you write a better RFP given these circumstances? Our Account Manager Allison Manley has seen hundreds of RFPs come through the door, and shares some thoughts on how to streamline your process and ask the right kinds of questions to get what you need, and make it easier for vendors you actually want to submit a proposal.

Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by This is a short podcast, just a couple minutes, that offers a quick tip on some small thing you can do to help your business run better. 

I’m Allison Manley, an account manager here at Palantir, and I’m the one offering today’s advice, which is about how to craft an RFP (which stands for Request for Proposal) in order to attract really good responses from firms like Palantir. 

RFPs are hard to craft, no doubt. You have to be concise, you likely have to insert a ton of legal jargon, but you want to create an appealing proposal that will attract the right firm for the job.

Over the years we have looked at a lot of RFPs, and have seen the good, the bad and the ugly. We thought it would be helpful to share our experience from the responder's side.

I’m going to outline the main five things you should consider. There are many more things to consider, and actually I outlined 15 of them in a blog post from March 2016 that is up at But here are the key five things I think you need to know. 

1. Be specific about your desired outcomes and goals
When outlining your goals, get as specific as possible. Even if you need just a general upgrade because your site is outdated in both the look and the technology, there must be a reason you’re frustrated with the old site: is it now too slow for back-end users to update? Does it need to be mobile-friendly? Do you want to increase traffic for a specific reason or conversion? Why do you want those things? What will they do for you that your current site can’t?

Try to also avoid generalities such as: "We want a website that incorporates social media,“ or “We want more traffic,” and “The site needs to convey our message and mission.” Because guess what: everyone wants those things, and they don’t give us enough information. When outlining projects, make sure to tie outcomes back to specific goals.

2. Give us a budget
From a bidder’s perspective, there’s probably nothing more frustrating than asking for a budget, only to be told “we don’t know. We’re trying to figure out how much this should cost.”

Let’s face it: there’s a number in your head. I know this because once I hear the basic parameters of the project, I’m going to respond with a range. And based on your reaction, I can get a sense of budget. I’ve had a lot of potential clients describe their needs, to which I’ll respond, “a similar project we did cost in the low six figures.” This is usually followed by a client saying, “oh, that’s fine” or “we don’t have more than mid-five figures to spend.”

See, you did have a number in mind! Even if it was your maximum cap.

Don’t ask for all the bells and whistles of a Porche-sized project if you know you only have the budget for a small Kia, or some similar car. Giving a budget upfront allows each firm bidding to tell you what they can offer you for your money. Then you can compare expertise and the value offered for your budget, which gains for you a more complete picture of what you're buying.

3. Be specific about constraints and exclusions
Are there certain key dates by which you would need your project completed? Are there brand and identity standards that we have to adhere to? What about third-party integrations that need to be considered? Giving us parameters helps us focus on what we can deliver for you.

Exclusions help define a project as well. What items will the bidders not be responsible for? Will someone else be in charge of photography and/or content creation? What about hosting and migration? Letting us know what not to bid on will ensure we don’t account for it as an unknown in our estimate.

4. Realize you are buying the process, not just the end product
Palantir didn't always work for healthcare clients. It took the trust and vision of our first healthcare client to give us the project to prove that we could. Consider responsive design: prior to 2011, nobody had ever heard of responsive design, let alone build anything for all devices, it just wasn’t done. But the smart firms all made a smooth transition to responsive.

Don't necessarily discount a firm because they've never done a project exactly like yours. Instead look for proof that they have related experience, are effective problem solvers, and have the creative and/or technical range required to complete your project successfully.

Conversely, the firm that does nothing but your particular type of project is unlikely to give you a solution much different than the one they produced for your competitor last year. Make sure you are dealing with firms that can effectively translate your message to your audience and not a production house offering cookie-cutter solutions.

5. Do not ever ask for spec work
Spec work is asking for work done prior to engagement with a client in anticipation of being paid. Never ask for examples of solutions as part of the RFP process. For one thing, professionals are paid for their ideas. Let’s face it: our ideas cost money. But more importantly, any quick solutions that a candidate would come up with before doing the proper in-depth research about your organization's culture and goals would simply be ill-informed and incomplete. Having strategic thinking guide your message is a much better bet than the "throw-it-at-the-wall-and-see-if-it-sticks so we can get the job" approach. Who wants to hope for a happy accident?

In conclusion
Writing a good RFP is not easy, I’m not gonna lie. It isn’t! It’s tough to get everything you want distilled down to a few pages (and in some cases impossible, since your organization may require many pages of legal attachments that need to be there).

The bottom line: make sure you are clear about what you need and why. Give us some solid parameters from which to work. Tell us what will make the project successful for you. This helps us suggest the best solutions to fit your needs. And leave the possibility open for a conversation with the bidders so they can ask follow up questions in case you missed anything.

And if you need assistance defining your project and writing your RFP, call us. We’d be happy to help show you a better way.

So that’s it for this week’s Secret Sauce. For more great tips, follow us on Twitter at @palantir, or visit our website at Have a great week, everybody!