<!-- Content Here -->

Where content meets technology

Dec 09, 2019

Hot Lots

When I start working with an established software development team, my favorite tool for understanding their process is a "hot lot." Hot lot is a manufacturing term where an order is expedited by being allowed to jump the queue. Hot lots are closely watched for progress and potential delays. In the world of software development, a hot lot can be a feature request that goes through a process of design, implementation, testing, enablement (documentation), release, promotion, and evaluation. A hot lot should accelerate the process by adjusting priorities but it should not circumvent the process by breaking rules or cutting corners.

By prioritizing a feature and watching it go through the process at top speed, you can learn many things. For example, you can learn...

  • Whether the process is even responsive enough to accept a hot lot. Sometimes engineering is tied to rigid roadmaps and nothing, no matter how important, can jump the line. This is concerning if those roadmaps stretch out beyond the opportunities you can reliably anticipate.
  • Whether there even is a defined process. Is there a mechanism for ensuring all of the tasks (qa, documentation, deployment, etc.) are completed? Or maybe there is a process but nobody follows it. If there is no practiced process, you can't trust the integrity of the system or whether anything is really "done."
  • How the process is structured into steps, roles, and hand-offs. How many people touch the feature? How much time does each step take? How much time is spent waiting between steps? Is there excessive back and forth? Lean Six Sigma has a great framework for studying process cycle time, wait times, and waste across the value stream.
  • The theoretical speed limit of the current process. You will never know how responsive your process can be when you always slow it down with competing priorities. Often actual speed is much slower than potential speed because of various delays, distractions, and interruptions that are not the fault of the process.
  • Whether there are structural blockers like "we only release every 3 months." Or maybe the team is distributed over many time zones with little overlap for hand-offs and feedback.
  • Whether there are capacity blocks like "Joe is the only person who can do that step and he is not available."
  • How easy it is to monitor the process. Can you go to one place and see the completed and remaining work?
  • The amount of managerial overhead that the process requires. For example, is there a project manager that needs to track and delegate every task?
  • The artifacts the process creates. Can you go back and see what was done and why?
  • How the response to the feature was measured and incorporated into future improvement ideas.

After running through a couple of these experiments, I have a pretty good understanding of the process structure, its theoretical speed, its strengths, and its flaws. At that point, we can start to come up with ideas for improvement. The low hanging fruit is usually pretty obvious ... especially to people who have been participating in the process but not paying attention to the overall throughput. Optimizations can be designed collaboratively and tested by future hot lots. I find that teams are generally comfortable with this evaluation because it doesn't target people as much as the framework that people work in. Usually processes (at least as they are practiced) form organically so nobody feels threatened by process improvements -- especially if they are clearly supported by empirical evidence.

Even if you have been working with a team for a while, try pushing through a hot lot and pay close attention to it. There is really no better way to understand the execution of a process.

Nov 07, 2019

What problem are we solving?

Before building any functionality, a product team should first start by fully understanding the problem they are being asked to solve. This may sound obvious but I can’t tell you how many times I see one-liner Jira tickets that ask for something without explaining why. But the “why” is the most important part for a number of reasons.

  1. The team has to agree that the problem exists and is worth solving. The impact and urgency is a primary factor in prioritization.
  2. Being grounded in the “why” informs creativity to answer the “what” and the “how.” Design begins with empathy and you can’t have empathy if you don’t know what your users are struggling with.
  3. Solutions should be evaluated on how well they address the problem. This evaluation should drive design, QA, and post-release review.

To help people focus on the problem, I use a simple tool that I call a “problem definition.” This is a document (preferably a wiki page) that describes the problem and why it is important: inefficiency, risk, etc. There is also a section for proposed solutions where the author can suggest their ideas. The problem definition then becomes a focal point for clarification and learning. Stakeholders can ask questions to explore the use case.

I think this type of document was the original intent behind the “User Story” used in various agile methodologies. But over time, the User Story has been corrupted into a formulaic and useless “As a _____, I want to ________ so I can ________”; I have yet to read a User Story that really got to the heart of the problem and why it was worth solving.

Problem definitions are precursors to project artifacts like specifications and work items. They should be easy for anyone to write in their own language. No commitment is made to implement a solution. Sometimes problems can be solved with training or better documentation. Even if no action is taken, expressing and hearing these issues is important in bridging the gap between the product team and its users.

Everyone on the team should be able to answer the question “why are we doing this?” If they can’t, they can’t be expected to be contribute to an effective solution.

May 23, 2019

Email is the portal

Aberdeen is a Market Intelligence company. We provide market data (Firmographic, Technographic, Leads, and Intent) as well as quantitative and qualitative insights based on those data. My primary role as Chief Technology Officer is to develop and improve products that deliver and maximize the value of these data and insights. This is really the same "right content, right context, right time" problem that I have been working on for years as a content management professional.

Our strategy for detail data is to push them directly to the systems where they are actionable. For example, our Aberdeen Intent for Salesforce app creates Salesforce opportunities out of companies that are showing intent. The Salesforce app also includes some charts to visualize summaries and trends. We also have other apps to help Salesforce users interact with our firmographic and technographic data. But Salesforce accounts are often rationed and not everyone spends their time there. The conventional answer to reach other users is a customer portal.

But does the world really need yet another portal?

Technical and non-technical roles are forced to work in so many different platforms. I feel especially bad for marketers (queue the scary Brinker SuperGraphic). But every office job today seems to involve logging into different systems to check in on various dashboards or consoles.

Yes, single sign-on can make authentication easier. But SSO is rarely configured because so few of these systems are owned by Corp IT. Plus, you need to remember where to go.

Yes, an email alert can suggest when it may be worthwhile to check in on a dashboard. But establishing the right threshold for notification involves time consuming trial and error that few have the patience for. It only takes a few "false alarm" notifications to make you hesitate before following a link.

Corporate portal technologies tried to solve this problem by assembling views (portlets) into one interface but the result was both unwieldy and incomplete. There is a constant flow of BI initiatives that try to solve this problem by bringing the data together into a unified place. Too complicated. Too cumbersome. And yet another place to go.

So most users are doomed to flit from portal to portal like a bee looking for nectar.

I am starting to believe that we already have the unified, integrated portal we have been looking for. It is the email client where we spend hours of every work day. Rather than develop a dashboard or portal that people need to go to, deliver simple glance-able email reports that highlight what is new/different and needs attention.

Longtime readers of this blog may be aware of my contempt for email as a collaboration and information management tool. However, even in the age of Slack, there is no more reliable way to notify business users than email. Decision makers live in their email clients. If you want to get information in front of someone, the best place to put it is in their inbox.

Designing email-friendly business intelligence is not trivial. Beyond the technical limitations of email clients' HTML rendering capabilities, you also have to consider the context. People are already overloaded with email so the reports need to minimize cognitive load. They need to quickly convey what is important within a couple distracted seconds. Perhaps even on a mobile phone in between meetings. Less is more - just a few Key Performance Indicators (KPIs) to make the user feel like he is in the loop and can answer questions about the status of the program or take action if necessary.

Frequency is also an important factor. The cadence should align with the decision making cycle. These emails are not for catching daily anomalies. Those types of warnings are better handled by system alerts that only go out when thresholds are met (behind schedule, over budget, no data detected...).

As I think about a portal to deliver Aberdeen's market intelligence insight, I keep going back to the question, what if our BI portal wasn't a portal at all? Wouldn't it be better to put our data into user interfaces that our clients are already looking at?

Oct 10, 2017

Release notes: the most important documentation you will ever write

One of my favorite high school teachers used to say "if you want to learn about the world, read the newspaper." This is great advice because, by updating you on what is happening now, newspaper articles expose you to places, people, and histories that you can dig into more with additional research.

I feel the same way about release notes. Let's face it, people don't read product manuals cover to cover any more than they do encyclopedias. You read a reference resource when you want to learn more about something that you are already aware of. In the product world, you read the manual when you are struggling to figure out how to use a feature. But what if you don't know a feature exists? That is where release notes come in.

If you practice lean product development, your product should be constantly improving so there should be plenty of material to talk about in release notes. You should also have an engaged customer base that likes the product, wants to learn new ways to use it, and is excited to know what is coming next. Release notes are the ideal channel to educate these customers about product features and progress. So make your release notes good!

While they are not release notes in a classic sense (because they are not tied to individual releases) a good model to follow is the "What's new with Alexa" emails that Amazon Echo owners get. These emails are easy to read and have just enough information to tease the reader into trying something and learning more. They also mention older features that new users may not have heard about yet. In fact, I am convinced that some weeks those emails only contain older features. But they are still useful reminders!

The redesigned App Store for iOS 11 also has some of these qualities.

I pay a lot of attention to release notes for all of the products I manage. Here are some habits that I think make them successful.

  • Write the first draft of the release notes at the start of a release cycle. That is, when the release is scoped and getting prepared for QA.
  • Invite internal stakeholders (especially sales, support, and QA) to review and comment on early release notes drafts. You might learn about functional issues that were not considered during the initial design. You may also learn about how to better describe/position the feature.
  • Make the release notes fun and easy to read. I find that humor are helpful in keeping the reader's attention.
  • Make release notes required reading for staff. After sending out the release notes, I email managers a quiz question to ask their team. 
  • Keep the notes short. Focus on what the change is and the problem it solves. Talking about the "why" is critical because it helps the reader understand what the feature is used for. For more details, link to longer form knowledge base articles or product documentation.
  • Include a "new to you" section that describes a pre-existing feature that is under-utilized or not widely known about. 
  • Copy the release notes into the Git merge commit message. This makes deployed versions stand out and searchable. 

Oct 03, 2017

Lean Product Development with SLCs rather than MVPs

I honestly can't think of a better way to build products and services than the lean product development method. All of the work I have done over the last several years has followed the pattern of growing a customer base around a small simple product that evolves and matures in response to the needs of the users.

Our latest product, Lionbridge onDemand, has been a great success and yet it started out so small: we were testing whether we could build a business around a self service video translation site. We built the simplest app possible but left room for growth. We leveraged operational talent that Lionbridge already had and an entrepreneurial spirit that was not being satisfied. We tested different ways to drive customers to the site. We got just enough market response to see a path and keep moving forward. Since our first sale, we have been constantly learning, optimizing, and expanding. Now onDemand is a thriving business with a broad range of services. We translate all sorts of content (over 40 file types) into pretty much any language you can think of. We have a public API and integrations with several popular content management and commerce systems. But most importantly, we have happy customers who rely on the service.

Whenever I want to build a new product, or even add a new feature to an existing product, my plan is to start with an MVP (minimum viable product) and iterate from there. But this article, "I hate MVPs. So do your customers. Make it SLC instead" by Jason Cohen, gave me pause. SLC stands for "Simple, Lovable, and Complete" and, after reading the article, I realize that SLCs are the recipe for success in lean product development; not MVPs.

Here is the difference. An MVP is (in a pure sense) the flimsiest thing you can build to answer a question about a potential market. The emphasis is more on the "M" (minimum) than the "V" (viability) and most interpret that balance as a semi functional prototype. This kind of MVP is frustrating to customers because it doesn't solve their problem in a helpful way. It focuses on validating that the problem exists and that there is value in solving it. MVPs are selfish because they prioritize research over actual customer benefit.

If you really want to learn about customer need, and build good relationships at the same time, you should take one customer problem and solve it well. Build an SLC. I know that the line is blurry here. An MVP could be an SLC if you make lovability a requirement for viability. But often you hear bad solutions as being excused or justified as "just an MVP."

The first iteration of Lionbridge onDemand did what was needed for a successful, gratifying transaction. In particular:

  • The customer could upload very large files. This is necessary because video files are big.
  • The project was automatically quoted so the customer didn't have to wait.
  • The customer could connect with an online sales agent through chat. This turned out to be a critical feature because we learned so much from our customers during these interactions.
  • The customer could pay for the service using a credit card so he/she got the experience of a seamless, self-service transaction.
  • The operations team was prepared to produce a high quality deliverable in a reasonable timeframe. The customer's need was satisfied.
While we launched the first iteration of Lionbridge onDemand quickly (less than 2 months from concept to first sale) we took the time to get those pieces right. That was a little over 4 years ago and our first customer continues to do business with us.

We are constantly adding new features to Lionbridge onDemand and every time we do, we treat it as an MVP SLC. We don't launch the feature unless it makes the user's experience a little better by solving a problem (however small) in a complete and satisfactory way.

Mar 16, 2015

The Three Worlds of a Product Manager

One of the most challenging aspects of being a product manager is that your mind needs to simultaneously exist in three worlds — three different realities: the present, the near future, and the distant future. Let's go through them one-by-one.

  1. The Present
    This is the state of the product that everyone is using right now. To the product manager, however, the present feels like the past because it contains features and characteristics that he thought through long ago. The most relevant function of the present is as a tool to learn more about users and decide what the near future should look like.
  2. The Near Future
    The near future feels like the present because it is the world that the product manager's mind spends most of its time in. The product manager is looking at mockups and prototypes and thinking about the sequence of when to deliver near future features. If you follow lean product development, release cycles are short and the actions are pragmatic and concrete. The picture of the near future is clear enough that it feels like present day. We do weekly releases so the near future can be real this week, the next, or the week after. If you use feature flags, the near future may be the current state for some users.
  3. The Distant Future
    The distant future may not be that far away on the calendar (maybe a few months), but to the product manager, it is science fiction. The distant future never arrives; pieces of it merge into the near future but the rest keeps on being pushed off. Because knowledge and priorities are constantly changing, the product manager can't get too attached to the distant future. More than likely, the product manager is juggling multiple possible distant futures simultaneously in his head. The whole purpose of the distant future is to put the near future into a larger context and to force the product manager to extrapolate where decisions for the near future may ultimately lead.

Your product exists in a different state in each of these parallel universes and you need to know every detail about each of these states because people look to you as the expert. It is hard to keep these details from getting muddled together in your head and harder still to not confuse others as you talk about the product.

The hardest time to avoid confusion is when discussing a product road map. The best approach is to talk about the near future. Stick to three months or less with the details weighted towards the first month. With this horizon you are safe to talk about sequencing and dates but the most important topic is "why?" You are rapidly responding to an opportunity, testing a hypothesis, or incrementally building towards something bigger. The reason for an enhancement should fall into one of those three categories. Describe the distant future as a vision that influences your general direction. Don't commit to details or dates. You just need to paint a picture that shows that the next steps in the journey are worth the effort.

The other time when the three worlds confuse stakeholders is when they request a feature. Often what they ask for fits into a larger vision. For example, they might ask you to fix something that you plan to replace with a different approach. You need to adjust your perspective to their present (which feels like your past) and then take them through time to show your plans for the near future. You might also need to take them forward a few releases more to describe how you want that feature to evolve.

Navigating back and forth across the present, near future, and distant future feels a lot like time travel. It is disorienting when you context-shift into a particular time period and sometimes the past feels a little embarrassing when you come back from the future. Like a hero in a time travel movie, sometimes you need to repair the future by going back into the past. There is never a dull moment in product management. If you think things are boring and routine, you need to get your mind over to where the action is.

Dec 08, 2014


Prioritizing is hard when other people's requests fight for your attention. It is stressful. You feel attacked; and when you constantly shift your priorities in response to whoever cries the loudest, you get nothing done and you feel defeated. As hard as it is to prioritize your own time, prioritizing what to improve in a product is even harder. The decisions you make on a product have such a large impact. Living under this stress of competing priorities is the life of a product manager. Here are some tricks that I learned.

  1. Create and publish a model for prioritization.
    My prioritization framework looks like this. Being transparent about how you prioritize serves three functions: it sets expectations; it encourages stakeholders to express their requests in terms that you can easily evaluate; and it forces you to adhere to your own rules.

  2. Don't elevate the priority of one request. Push everything else down.
    It is easy to fall into a cycle of urgency inflation where each request tries to one-up the others in priority. Hysteria builds and you go into reaction mode as you try to keep up. When I feel like this, I try to visualize calmly but firmly pushing other requests down. You only have so much capacity. The highest priority thing should be whatever you are working on right now. It can't get any higher than that. Everything else will have to wait. It feels empowering to actively push requests down to make room for the one request that cannot be deferred. The alternative is passively accepting every request's own self stated importance. That feels horrible.

  3. Group niggling little things into a single item.
    One risk of prioritization is that some of the little things never get done. Individually, these details never get to the top of the stack. But in aggregate, they do matter. User experience is all about the details — sanding down the snags that get in the way of delight. To solve this, I like to group some of these requests together to give them a fighting chance against some of the larger initiatives.

  4. Strive for continuous improvement rather than immediate perfection.
    Your application is not perfect today and, no matter what you do, it will not be perfect next month. Rather that succumbing to the pressure of immediate perfection, focus on continuous improvement. One of my favorite articles about product management is "Make it Suck Less." While this sounds like an overly humble goal, software would be a whole lot better if every application was managed on this principle. Besides, if you achieved perfection, your job as a product manager would be over.

  5. Take a moment to celebrate your achievements.
    After you launch a new feature, resist the temptation to immediately jump to the next thing. Get closure by reflecting on what you accomplished. This will help in two ways: it will get you off the treadmill for a moment to enjoy your success; and it will allow you to evaluate what efforts have yielded the greatest impact so that you can be even more effective with your prioritization. Personally, I find the best time for this reflection is when reviewing release notes before publication and when preparing for a team retrospective.

These practices work for me in product managing my own time. Hopefully you will find them useful too.

Sep 02, 2014

Radio Silence

You might have noticed that I haven't been posting here much over the last year. More likely, you haven't noticed at all. Blogs are often like that. They come and go depending on the whims of the blogger.

The reason for my silence is that my focus has shifted from pure content management to lean product development, web application development, and cloud-base architecture. At Lionbridge, I have been helping to build a business called Lionbridge onDemand. It has been a little over a year since our first sale and I am in a constant state of amazement about how things are growing. Like most of my projects, we followed a lean product development model of launching a minimum viable product and continually improving it to support the needs of our growing customer base. In this case, we started with a tiny website to translate videos. Since then we have grown to the point where:

  • We now have a wide array of services that support nearly 40 different content types. We even have services that do not involve translation at all such as proof reading and CRM data cleanup.

  • There are enterprise sites for many name-brand clients. It turns out that large organizations are full of individuals who prefer a simple consumer style eCommerce experience. With onDemand Enterprise, we can quickly create a custom site for a corporate account. These enterprise sites have the same simple "consumer" feel but they also have the ability to offer custom services and can tap into corporate payment channels.

  • We have a Public API with a developer program. We started with an API for eCommerce systems to translate product catalogs; but then we grew into a full featured translation API that can handle our full complement of content types. While there are other translation APIs out there, ours is unique because it exposes different translation services ranging from pure machine translation to professional translation by subject matter specialists.

  • We are now a global team working around the clock to deliver projects with industry leading quality. We have operations specialists in North America, Europe, and Asia. Managing a service like this requires a special mix of problem solving skills. This is content management at a level of complexity that I have not seen before. The process requires the constant attention of highly skilled and conscientious individuals.

The last point is my favorite. I am currently en route from Warsaw, Poland where I have spent the last five weeks working with the operations core team. It was an incredible experience to meet the people that I had only known through email and conference calls. From the start, I was impressed by their dedication and can do spirit. Now they feel like family.

So, back to this blog. What has made Content Here a worthy endeavor so far was that it provided a useful place for me to explore observations and concepts that I encountered as a content management professional. If I learned something, I would flesh out my knowledge by writing it here. If I did a decent job of explaining something to someone, I would reproduce that explanation here. If that was all blogging did for me, it would have been enough. But blogging provided so many more benefits. In particular, it was a way to connect with other people. I made many business connections and friendships with this blog.

I am hoping that I can continue experiencing these benefits by shifting the focus of this blog to be more aligned with my day to day work. It won't be a total departure from my older posts. My involvement in web development and open source software has stayed the same. But I will probably write a lot less about content management software, product selection, taxonomy, workflow, and other pure content management concepts. To be honest, I feel like there is not much more for me to write on those topics. There will be more posts about my experiences from growing a web business. Topics will include things like working with distributed teams, lean product development, customer support, web application development, and web operations.

Hopefully, along the way, I will meet new people who are struggling with these same topics. The web is a pretty big place so I think that chances are good.

Aug 21, 2013

Small Deployments

Last week, when we released a new version of Lionbridge onDemand, I was reminded of a valuable lesson: keep your deployments small. Up to that point, we had been upgrading the production environment on a regular basis — nearly daily. When a new feature was ready, we deployed it. But this development iteration had some systemic improvements (new service types, enterprise features…) so we held off to release everything at once. That was a mistake. The problem was that lots of configuration changes had been building up (new settings, new libraries on the server, etc.) and that led to a lot more work at launch time. As you would expect, some steps were missed that compromised functionality. It wasn't a huge deal. Nothing was obviously broken. There were just some "Oh SNAP!" moments along the way.

Thanks to that reminder, we are back on schedule with regular code deployments. Some of the updates will be "under the waterline" — invisible changes to the underlying architecture to support visitor facing features that we are still working on. The trick is to keep the back-log of un-deployed code to a minimum. In addition to reducing the risk of the actual deployment, smaller upgrades make it easier to troubleshoot issues because there are fewer potential causes. For further reading on this topic read Eric Reis's chapter on Continuous Deployment in Web Operations: Keeping the Data On Time

. David Hobbs also has some great articles on this topic in relation to website launches. The one that springs to mind is Site Launches: do as little as possible. Also, to work in this way, it is also critical that you use a mature code management strategy. A couple of months ago my team adopted the Git Flow branching strategy and it has been a huge help.

People getting used to this model of product management will find it counter-intuitive. They see upgrades as risky, scary things and the natural tendency is to avoid them. But the more you delay an upgrade, the scarier and riskier it gets. And that creates a vicious circle. Even if you know and agree with the small deployment approach, it is easy to justify delaying an upgrade because you want to do one more thing. That is what happened to me.

Jun 13, 2013

The Website is Launched, the Journey Begins

We have all been there. We launch a new website and, interspersed with general praise and appreciation, there are some hysterical complaints about trivial things like a word-wrap or a punctuation mark. The tone on these emails is similar to someone who just received their huge wedding invitation order and saw that their name was misspelled. They are mad and want immediate resolution to avoid mortal embarrassment on their special day. Ironically, it doesn't seem to matter that the old website was a total disaster. This site is new. It should be perfect.

If you are on the receiving end of one of these complaints, you know how easy the issue is to fix. You know it is nothing like re-printing 500 wedding invitations with gold leaf on expensive paper. You just edit the content in your CMS and republish. In fact, you fixed the problem in the two minutes that elapsed between receiving the urgent-flagged email and the frantic follow-up call. You also know that the content that is the target of the complaint has a shelf life of only a couple of days. In fact, you consider the entire website to be dynamic and constantly evolving. What you launched was not a bunch of static pages but new layouts, branding, and infrastructure to support your dynamic digital marketing program.

In retrospect, it is easy to see where the disconnect started. The internal audience for the site had not seen anything since they fell in love with the mockups. And the mockups were perfect — artificially perfect. The designer put in just enough text to make the layout look full, but not crowded. The PDFs that were distributed didn't depend on a specific screen resolution or browser. The audience was expecting to see those polished PDFs sitting in their browser on launch day; but what they got wasn't exactly the same. Add that to the fact that the web team appeared to vanish after the last site was launched and their anxiety is understandable.

How do we correct this? The number one thing you need to do is keep up the pace. You can't take a break after the new site is launched because that leaves the impression that the site is "complete." You know that launch day marks the beginning of a new phase of your digital marketing program, but if you act like you think your are done, you are bound to get into discussions with people trying to prove to you that you are not. The conversation invariably focuses on the site being "defective" rather than what it really is: a work in progress. Keep the site changing and be transparent with your road map. Regularly communicate with people who have ideas and update them on your progress.

Also, justify your decisions with data. When you relaunch a site, people will often look for their old content to make sure it is still there. If you removed it or re-organized their content, be prepared to explain why. The traffic was low, the content was redundant, the page was competing with more important pages on search results… these are all good reasons to retire a page. The fact that you can respond in this way shows that you are still engaged and moving forward in a thoughtful way. This will further re-enforce the idea that this is a journey and you are a competent and attentive driver.

Depending on your organization's culture and history, breaking out of a "print-final website" mindset might be easy or hard. Generally, the more web savvy your internal audience is, the easier it will be to change people's minds. The older guard will be more difficult to convince. Your line of reasoning should go like this:

Remember how perfect the last website seemed at launch? Well, it only seemed perfect because it was rigid. The designers got it just right and then locked it down through QA. But it was also brittle and it started to crumble from the moment we started to change content. New browser versions and platforms only hastened its decay. This new website is part of a program that involves continuous improvement. It will improve, rather than degrade, over time.

The key is to sell internal stakeholders on the idea that your website is a constantly evolving asset that will never be perfect but will be always be good (or even great). The site will adapt to changing organizational goals and audience expectations. Like the original meaning of the term "launch," putting up a new website should be considered the beginning of a journey, not the end of a project.

Related: Your Website is not a Project.

Next → Page 1 of 2